RFR: 8369658: Client emulation mode sets MaxRAM too late

[Stefan Karlsson]

On Mon, 13 Oct 2025 11:25:04 GMT, Joel Sikström <jsikstro at openjdk.org> wrote:

> Hello,
> 
> While working on the proposal for the potential deprecation of MaxRAM (see [JDK-8369347](https://bugs.openjdk.org/browse/JDK-8369347)) I saw that `CompilerConfig::ergo_initialize()` sets the value for `MaxRAM` after ergonomic heap sizing is already done, which is the only place in the VM that cares about `MaxRAM`. I suggest we move setting the value of `MaxRAM` to `Arguments::set_heap_size()` to fix this.
> 
> Even though the `MaxRAM` flag might be deprecated, the code should still account for the fact that client emulation mode might lower the maximum amount of physical memory that can be used for the Java heap. If the flag is removed, we'd still want to lower the maximum memory, so it makes sense to have the code in `Arguments::set_heap_size()` in both cases.
> 
> Testing:
> * Currently running Oracle's tier1-2
> * Local test with `java -XX:+NeverActAsServerClassMachine -Xlog:gc+init` to see that the lower limit is reflected in ergonomic heap sizing.

> Especially after JEP-523.

The `NeverActAsServerClassMachine` and `AlwaysActAsServerClassMachine` flags don't seem to be well-known and frequently used flags. If we are moving towards JEP-523 (Make G1 the Default Garbage Collector in All Environments), should we also take the opportunity to get rid of these flags to lower the maintenance cost / risk of having these flags?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27765#pullrequestreview-3334197621