Set MaxRAM and MaxRAMPercentage in launcher for native-image driver

[zakkak]

See #7277 (comment) for motivation.

We have been using this as the default in Mandrel since the 23.1 release.

[jerboaa]

This would bring the shell/cmd launchers on par with the native image version of the launcher.

[fniephaus]

This would bring the shell/cmd launchers on par with the native image version of the launcher.

Sure that makes sense, although this changes it for all users of the launcher scripts, including Truffle languages, no?

[jerboaa]

This would bring the shell/cmd launchers on par with the native image version of the launcher.

Sure that makes sense, although this changes it for all users of the launcher scripts, including Truffle languages, no?

Yes. We have no experience with those. If they have a similar setup of launching a JVM process driving native-image generation, it should still be a safe option to use those. I.e. keep the launching process (which is usually tiny) within certain bounds.

[fniephaus]

Yes. We have no experience with those.

Ok, let me take a look at this in the next couple of days.

[ansalond]

launcher_template.sh and launcher_template.cmd are used to generate bash/cmd launchers for every LauncherConfig that is not built as a native image. This includes, for example, the Toolchain launchers, which pass a different main class.

Rather than modifying the templates, I would pass these Java arguments to the extra_jvm_args of the native-image LauncherConfig: https://github.com/oracle/graal/blob/master/substratevm/mx.substratevm/mx_substratevm.py#L1096

For example:

diff --git a/substratevm/mx.substratevm/mx_substratevm.py b/substratevm/mx.substratevm/mx_substratevm.py
index 9456bd5759a..73983df49ed 100644
--- a/substratevm/mx.substratevm/mx_substratevm.py
+++ b/substratevm/mx.substratevm/mx_substratevm.py
@@ -1054,7 +1054,7 @@ def _native_image_launcher_extra_jvm_args():
     Gets the extra JVM args needed for running com.oracle.svm.driver.NativeImage.
     """
     # Support for running as Java module
-    res = []
+    res = ['-XX:MaxRAM=256m', '-XX:MaxRAMPercentage=80']
     if not mx_sdk_vm.jdk_enables_jvmci_by_default(get_jdk()):
         res.extend(['-XX:+UnlockExperimentalVMOptions', '-XX:+EnableJVMCI'])
     return res

[ansalond]

BTW, should we pass only -Xmx256m instead of -XX:MaxRAM=256m -XX:MaxRAMPercentage=80?

Looking at #7277 (comment), this seems closer to what the native version does.

[fniephaus]

BTW, should we pass only -Xmx256m instead of -XX:MaxRAM=256m -XX:MaxRAMPercentage=80?

+1, Xmx seems more standard. On a machine with 64GB memory, I get a max heap of 206M with the two flags, and on one with 1GB I get 199.19M (see below). So maybe fine-tuning is not really worth it?

64GB machine$ java -XX:MaxRAM=256m -XX:MaxRAMPercentage=80 -XshowSettings:vm -version
VM settings:
    Max. Heap Size (Estimated): 206.00M
    Using VM: Java HotSpot(TM) 64-Bit Server VM

java version "21.0.2" 2024-01-16 LTS
Java(TM) SE Runtime Environment Oracle GraalVM 21.0.2+13.1 (build 21.0.2+13-LTS-jvmci-23.1-b30)
Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 21.0.2+13.1 (build 21.0.2+13-LTS-jvmci-23.1-b30, mixed mode, sharing)

1GB machine $ java -XX:MaxRAM=256m -XX:MaxRAMPercentage=80 -XshowSettings:vm -version
VM settings:
    Max. Heap Size (Estimated): 199.19M
    Using VM: Java HotSpot(TM) 64-Bit Server VM

java version "21.0.2" 2024-01-16 LTS
Java(TM) SE Runtime Environment Oracle GraalVM 21.0.2+13.1 (build 21.0.2+13-LTS-jvmci-23.1-b30)
Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 21.0.2+13.1 (build 21.0.2+13-LTS-jvmci-23.1-b30, mixed mode, sharing)

[jerboaa]

BTW, should we pass only -Xmx256m instead of -XX:MaxRAM=256m -XX:MaxRAMPercentage=80?

No. -XX:MaxRAMPercentage has no effect if you set -XX:MaxHeapSize (which is what the short form, -Xmx, is using). MaxRAMPercentage is being used as a percentage of "physical memory". By setting MaxRAM, you tell the JVM to use that for "physical memory". So the effect is that -Xmx will be 80% of 256mb. What you want to tell the JVM that launches the actual native image driver process, is to keep within 256mb including metaspace, jit code blobs, etc. Use most of it for heap, though.

[jerboaa]

Rather than modifying the templates, I would pass these Java arguments to the extra_jvm_args of the native-image LauncherConfig: https://github.com/oracle/graal/blob/master/substratevm/mx.substratevm/mx_substratevm.py#L1096

For example:

diff --git a/substratevm/mx.substratevm/mx_substratevm.py b/substratevm/mx.substratevm/mx_substratevm.py
index 9456bd5759a..73983df49ed 100644
--- a/substratevm/mx.substratevm/mx_substratevm.py
+++ b/substratevm/mx.substratevm/mx_substratevm.py
@@ -1054,7 +1054,7 @@ def _native_image_launcher_extra_jvm_args():
     Gets the extra JVM args needed for running com.oracle.svm.driver.NativeImage.
     """
     # Support for running as Java module
-    res = []
+    res = ['-XX:MaxRAM=256m', '-XX:MaxRAMPercentage=80']
     if not mx_sdk_vm.jdk_enables_jvmci_by_default(get_jdk()):
         res.extend(['-XX:+UnlockExperimentalVMOptions', '-XX:+EnableJVMCI'])
     return res

That makes sense, thanks!

[jerboaa]

We could of course set -XX:MaxRAM=256mb/0.8 -XX:MaxRAMPercentage=80 if you want to exactly match native image.

[fniephaus]

No. -XX:MaxRAMPercentage has no effect if you set -XX:MaxHeapSize (which is what the short form, -Xmx, is using).

I think @ansalond was suggesting to replace both flags with just the -Xmx flag.

[jerboaa]

No. -XX:MaxRAMPercentage has no effect if you set -XX:MaxHeapSize (which is what the short form, -Xmx, is using).

I think @ansalond was suggesting to replace both flags with just the -Xmx flag.

Sure. I'm arguing that it makes more sense to set MaxRAM and MaxRAMPercentage as you can then easier reason about what the rest of the system will get. The point is with both flags, you restrict the whole tiny JVM process, which simply launches the generator, to stay within that setting. You also know what the heap chunk will be.

[fniephaus]

Ok, let's go with the two flags then, especially because they have been tested with Mandrel.

@zakkak could you update the PR according to #8366 (comment)? Otherwise, I can take care of it and make the adjustment when merging your other PR.

[fniephaus]

Let me take care of it, will share a PR when it's ready.

[zakkak]

Let me take care of it, will share a PR when it's ready.

OK if that works better for you, thanks @fniephaus.

[zakkak]

Superseded by #8384