Add support for MaxRAM restriction for the native image driver process

[jerboaa]

When GraalVM Community for JDK 21 (internal version 23.1) comes out the native-image driver will limit itself with a heap size of 256MB. See oracle#7277 (comment)

Mandrel uses the bash launcher which doesn't impose a limit for the driver process. Note that a regular native-image build goes like this:

 <driver-process>
     `-> <generator-process>

So in a container build you have two processes running possibly competing for resources. It makes sense to keep the driver process with certain bounds. The native-launcher (macro --macro:native-image-launcher) will do that.

[jerboaa]

For the bash launcher some MaxRAM setting should be the way to go.

[zakkak]

@jerboaa I did some measurements and it looks like the maximum RSS of NativeImage is in the range of 140k -- 150k. To my understanding this implies that there won't be much competition for resources even if we don't constrain it.

I tried setting Xmx to 128m and it resulted in similar RSS usage, same when setting Xmx to 256m.

I believe adopting the upstream limit of 256MB is OK if we really want to constraint its memory usage.

[jerboaa]

@zakkak Yes, we really should constrain it. But we should set MaxRAM and a fixed MaxRAMPercentage for heap. Setting -Xmx alone only limits heap, not other native memory usage. Why should we constrain it? 1) for better reasoning of native-image builds within containers (since we can reason about memory consumption of the driver by the set upper limit). 2) to avoid memory leaks and those leaking to the builder process.

[zakkak]

So what about -XX:MaxRAM=256m -XX:MaxRAMPercentage=5

Assuming we need a machine with at least 4G of RAM (@Karm may have used less though in some of his experiments) to build a native image the minimum MAXRam according to MaxRAMPercentage would be ~200M and the highest will be 256M.

[jerboaa]

-XX:MaxRAM=256m -XX:MaxRAMPercentage=5

It looks odd. If MaxRAM=256 (for the driver), MaxRAMPercentage=5 would mean use "5% of 256MB for max heap" before running into OutOfMemory if I'm not mistaken. It seems 80% would make more sense. What we need to be careful about is that those options don't populate to the builder process (not sure if that's the case currently).

[jerboaa]

Feel free to test with something like:

java -XX:MaxRAM=500m -XX:MaxRAMPercentage=80 -XX:+PrintFlagsFinal --version 2>&1 | grep MaxHeapSize

[zakkak]

I see, I misunderstood the MaxRAMPercentage option, which now makes me curious why the default value is only 25!

If the percentage refers to the MaxRAM value and not the actual RAM size I agree with 80% making sense and being enough for the driver.

[zakkak]

What we need to be careful about is that those options don't populate to the builder process (not sure if that's the case currently).

According to my tests they don't populate to the builder process, we would need to use -J-XX... for that.

[jerboaa]

I see, I misunderstood the MaxRAMPercentage option, which now makes me curious why the default value is only 25!

Historic reasons. It makes sense for multi-user systems. Not so much for containers with a single process and a single JVM.

[jerboaa]

What we need to be careful about is that those options don't populate to the builder process (not sure if that's the case currently).

According to my tests they don't populate to the builder process, we would need to use -J-XX... for that.

Great!

[zakkak]

Fixed for 23.1 in graalvm/mandrel-packaging#365