Java / GraalVM Interview questions
Why is heap size configuration different for native image versus a JVM?
A standard JVM defaults its heap sizing based on available system memory and lets you tune it with familiar flags like -Xmx and -Xms at launch, with HotSpot's ergonomics adjusting things like young-generation size dynamically.
A native image executable embeds its own garbage collector (Serial GC by default in Community Edition, with G1 available on Oracle GraalVM), and while it accepts similar-looking runtime flags (-Xmx, -Xmn) at launch time, some GC-related tuning must instead be baked in at build time via -R: flags, because the GC implementation itself is selected and partly configured when the executable is compiled, not when it's run.
native-image -R:MaxHeapSize=256m -jar app.jar ./app -Xmx256m
In practice this means teams need to think about two separate configuration surfaces - build-time GC selection/limits and run-time heap flags - rather than the single unified runtime flag set they're used to on a normal JVM.
More Related questions...