[GR-45673] Tweak GC settings of Native Image builder. #6432
Conversation
oracle-contributor-agreement
bot
added
the
OCA Verified
graalvmbot
force-pushed
the
fniephaus/GR-45673/builder-max-heap
branch
from
44ab73c to
6572935
Compare
graalvmbot
force-pushed
the
fniephaus/GR-45673/builder-max-heap
branch
from
6572935 to
2614e93
Compare
fniephaus
changed the title
graalvmbot
force-pushed
the
fniephaus/GR-45673/builder-max-heap
branch
7 times, most recently
from
0dc82ed to
4f8706e
Compare
graalvmbot
force-pushed
the
fniephaus/GR-45673/builder-max-heap
branch
from
4f8706e to
c5d0252
Compare
fniephaus
changed the title
Optimize for throughput and take available memory into account to reduce memory pressure.
graalvmbot
force-pushed
the
fniephaus/GR-45673/builder-max-heap
branch
2 times, most recently
from
b8cb61d to
64dbd4f
Compare
| reasonableMaxMemorySize = switch (OS.getCurrent()) { | ||
| case LINUX -> getAvailableMemorySizeLinux(); | ||
| case DARWIN -> getAvailableMemorySizeDarwin(); | ||
| case WINDOWS -> getAvailableMemorySizeWindows(); | ||
| }; |
There was a problem hiding this comment.
Why not use osBean.getFreeMemorySize()?
There was a problem hiding this comment.
Free memory can be much lower than available memory due to OS caches etc, especially on long running developer machines.
There was a problem hiding this comment.
This is from a cloud machine I ran for 20min:
MiB Mem : 7645.6 total, 134.0 free, 3298.8 used, 4212.8 buff/cache
Native Image wouldn't start if we set the max heap to 134MiB.
| private static long getAvailableMemorySizeLinux() { | ||
| try { | ||
| String memAvailableLine = Files.readAllLines(Paths.get("/proc/meminfo")).stream().filter(l -> l.startsWith("MemAvailable")).findFirst().orElse(""); | ||
| Matcher m = Pattern.compile("^MemAvailable:\\s+(\\d+) kB").matcher(memAvailableLine); |
There was a problem hiding this comment.
Note that this metric is not container aware. I.e. on large systems, say with 1TB of memory, and a container slice of say 50GB you'd still get > 32 Gib since 50/0.8 > 32. Using the OSBean could solve this problem.
There was a problem hiding this comment.
Good point and yes, in that case reasonableMaxMemorySize > totalMemorySize is true, so this would return the 80% fallback which actually matches the current behavior (80% of total memory). OSBean takes cgroups into account but it unfortunately only provides access to free, not available memory. Do you have any other suggestions how we could handle such cases?
There was a problem hiding this comment.
Following up on this in #6581.
This PR revises the GC settings of the Native Image builder. It now takes available memory into account to reduce memory pressure, which should make host machines more responsive during development and out-of-memory scenarios less likely. We also optimize for throughput by allowing for more time spent in the GC, which also reduces peak memory usage.