Allow 4G memories by default in the pooling allocator (bytecodeallian…

…ce#8849)

This commit raises the default setting of `max_memory_size` in the
pooling allocator from 10M to 4G. This won't actually impact the virtual
memory reserved in the pooling allocator because we already reserved 6G
of virtual memory for each linear memory this instead allows access to
all of it by default. This matches the default behavior of Wasmtime for
the non-pooling allocator which is to not artificially limit memory by
default.

The main impact of this setting is that the memory-protection-keys
feature, which is disabled by default, will have no effect by default
unless `max_memory_size` is also configured to something smaller than
4G. The documentation has been updated to this effect.

Closes bytecodealliance#8846

crates/wasmtime/src/config.rs

@@ -2759,7 +2759,9 @@ impl PoolingAllocationConfig {
 
     /// The maximum byte size that any WebAssembly linear memory may grow to.
     ///
-    /// This option defaults to 10 MiB.
+    /// This option defaults to 4 GiB meaning that for 32-bit linear memories
+    /// there is no restrictions. 64-bit linear memories will not be allowed to
+    /// grow beyond 4 GiB by default.
     ///
     /// If a memory's minimum size is greater than this value, the module will
     /// fail to instantiate.
@@ -2769,11 +2771,15 @@ impl PoolingAllocationConfig {
     /// instruction.
     ///
     /// This value is used to control the maximum accessible space for each
-    /// linear memory of a core instance.
-    ///
-    /// The reservation size of each linear memory is controlled by the
-    /// `static_memory_maximum_size` setting and this value cannot exceed the
-    /// configured static memory maximum size.
+    /// linear memory of a core instance. This can be thought of as a simple
+    /// mechanism like [`Store::limiter`](crate::Store::limiter) to limit memory
+    /// at runtime. This value can also affect striping/coloring behavior when
+    /// used in conjunction with
+    /// [`memory_protection_keys`](PoolingAllocationConfig::memory_protection_keys).
+    ///
+    /// The virtual memory reservation size of each linear memory is controlled
+    /// by the [`Config::static_memory_maximum_size`] setting and this method's
+    /// configuration cannot exceed [`Config::static_memory_maximum_size`].
     pub fn max_memory_size(&mut self, bytes: usize) -> &mut Self {
         self.config.limits.max_memory_size = bytes;
         self
@@ -2790,6 +2796,11 @@ impl PoolingAllocationConfig {
     /// regions are accessible each time executions switches from host to guest
     /// (or vice versa).
     ///
+    /// Leveraging MPK requires configuring a smaller-than-default
+    /// [`max_memory_size`](PoolingAllocationConfig::max_memory_size) to enable
+    /// this coloring/striping behavior. For example embeddings might want to
+    /// reduce the default 4G allowance to 128M.
+    ///
     /// MPK is only available on Linux (called `pku` there) and recent x86
     /// systems; we check for MPK support at runtime by examining the `CPUID`
     /// register. This configuration setting can be in three states:

crates/wasmtime/src/runtime/vm/instance/allocator/pooling.rs

@@ -166,7 +166,7 @@ impl Default for InstanceLimits {
             // have 10k+ elements.
             table_elements: 20_000,
             max_memories_per_module: 1,
-            max_memory_size: 10 * (1 << 20), // 10 MiB
+            max_memory_size: 1 << 32, // 4G,
             #[cfg(feature = "gc")]
             total_gc_heaps: 1000,
         }