diff --git a/ApplicationDeveloperGuide/managedc/binding.rst b/ApplicationDeveloperGuide/managedc/binding.rst
index 98600eb3f..a7279540a 100644
--- a/ApplicationDeveloperGuide/managedc/binding.rst
+++ b/ApplicationDeveloperGuide/managedc/binding.rst
@@ -416,14 +416,13 @@ SOAR will trigger an error if Managed C function parameter(s) and return types d
 
 .. _managedc.communication.managedc_memory:
 
-Manipulate Managed C Memory from Java
--------------------------------------
-
-The Core Engine allows to expose Managed C memory to Java code. A Managed C module contains 
-at most one memory. This Managed C module memory is automatically generated by the C compiler 
-according to C source code and C compiler options. On Java side, Managed C module memory can be seen by
-using ``@WasmMemory`` annotation on a Java static byte array field declaration (mapping automatically 
-done by the :ref:`soar`).
+Access Managed C Memory from Java
+---------------------------------
+
+The Managed C memory is composed of all static arrays, structures, globals declared in C files, thread stacks and optional heap for dynamic allocations. 
+All these elements are :ref:`linked <managedc.link.module>` to the :ref:`Wasm module linear memory <managedc.linear.memory>`.
+
+On Java side, the Wasm module linear memory can be bound to a Java static byte array field declaration using the ``@WasmMemory`` annotation.
 
 .. note:: 
    A SOAR error will occurred if ``@WasmMemory`` is not strictly followed by a Java static byte array declaration (see :ref:`managedc.troubleshooting`).
diff --git a/ApplicationDeveloperGuide/managedc/troubleshooting.rst b/ApplicationDeveloperGuide/managedc/troubleshooting.rst
index 48f9fa9d4..2119c618a 100644
--- a/ApplicationDeveloperGuide/managedc/troubleshooting.rst
+++ b/ApplicationDeveloperGuide/managedc/troubleshooting.rst
@@ -96,6 +96,22 @@ Running code containing Managed C in a simulation will prompt an error similar t
 Runtime Errors
 ~~~~~~~~~~~~~~
 
+--------------------------
+java.lang.OutOfMemoryError
+--------------------------
+
+If you encounter a stack trace like the following, there is insufficient space in the Managed Heap to allocate a Wasm module linear memory.
+Increase the :ref:`Managed Heap size <option_managed_heap>` or :ref:`reduce the linear memory size <managedc.linear.memory.size.configuration>` of the Wasm module.
+
+.. code:: console
+
+  java.lang.OutOfMemoryErrorM:0x808d2c8:0x808d2d3@
+          at com.mycompany.MyApplication.<clinit>(Unknown Source)
+          at java.lang.Thread.execClinit(Unknown Source)
+          at java.lang.Thread.clinitWrapper(Thread.java:484)
+          at java.lang.Thread.callWrapper(Thread.java:450)
+
+
 -----------------------------
 java.lang.AssertionError
 -----------------------------
diff --git a/ApplicationDeveloperGuide/managedc/wasi.rst b/ApplicationDeveloperGuide/managedc/wasi.rst
index 70791601a..2cc9f55b1 100644
--- a/ApplicationDeveloperGuide/managedc/wasi.rst
+++ b/ApplicationDeveloperGuide/managedc/wasi.rst
@@ -47,7 +47,7 @@ Here is an example:
         void print_time() {
             struct timespec ts;
             clock_gettime(CLOCK_REALTIME, &ts);
-            printf("%lld.%.9ld", (long long)ts.tv_sec, ts.tv_nsec);
+            printf("%lld.%.9ld\n", (long long)ts.tv_sec, ts.tv_nsec);
         }
 
 
@@ -72,7 +72,7 @@ Here is an example:
             public static void main(String[] args) throws IOException {
             
                 // Initialize WASI with the memory of my_app module and no preopened directories
-                Wasi.init(Memory, null);
+                Wasi.init(Memory);
 
                 // Call and the "print_time" Wasm function
                 printTime();
@@ -87,11 +87,8 @@ In this example, the implementation of The POSIX-compliant C functions ``clock_g
 
 .. note:: 
 
-  WASI cannot be used in more than one Wasm module in a `Standalone Application <standalone_application>`; otherwise calls to WASI methods will result in undefined behavior.
-
-  In a `Sandboxed Application <sandboxed_application>`, WASI methods must not be exposed in the `Kernel API <kernel.api>` and each Application and the Kernel can use WASI in only one module.
-
-  Using WASI in multiple modules within an Application or the Kernel will result in undefined behavior.
+  WASI cannot be used by more than one Wasm module within a single Application. Otherwise, calls to WASI methods may result in undefined behavior.
+  In particular, in Multi-Sandbox mode, WASI APIs must not be exposed as :ref:`Kernel APIs <kernel.api>`. This restriction allows each Application and the Kernel to use WASI independently, while still limiting usage to a single Wasm module per context.
 
 
 WASI APIs