RFR: 8369658: Client emulation mode sets MaxRAM too late

[Axel Boldt-Christmas]

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.

Looks good, I see little risk with taking the patch as is. I had one suggestion for making `should_set_client_emulation_mode_flags` a bit more robust / less scary. 

Sidenote:
`NeverActAsServerClassMachine` in the java.md seems to suggest that `MaxRAM` is "The maximum amount of memory that the JVM may use". While its section on `MaxRAM` explicitly says it is only for the java heap.

Sidenote2:
`NeverActAsServerClassMachine` and `AlwaysActAsServerClassMachine` seem very scewed. First that we allow them to be contradictory, `NeverActAsServerClassMachine` outweighs `AlwaysActAsServerClassMachine`, and we only care about `AlwaysActAsServerClassMachine` for the GC selection, but not the compiler. I wonder if the compiler also should have used `is_server_class_machine`. But regardless, the best thing is probably just to not change behaviour and hopefully be able to remove the flags in the future. At least consolidate them into one flag. Especially after JEP-523.

src/hotspot/share/compiler/compilerDefinitions.cpp line 562:

> 560:       }
> 561:     } else if (!has_c2() && !is_jvmci_compiler()) {
> 562:       return true;

Pre-existing: 
Just a note that this `!has_c2` seems so strange, as we set the values that are set inside `set_client_emulation_mode_flags();` to other defaults than those in `c1_globals_<arch>.hpp`. So we override those defaults here always. Some defaults seem to be the same but some are different. Which seems very strange.  `CICompilerCount` is the only flag which is not from that file but its default is also correctly 1 if c2 has been built out.

src/hotspot/share/compiler/compilerDefinitions.cpp line 576:

> 574:   if (should_set_client_emulation_mode_flags()) {
> 575:     set_client_emulation_mode_flags();
> 576:   }

Should there be a comment here which mentions that this decision has already been taken (and acted on) in `GCArguments::set_heap_size`?

 Someone that is not aware might start ergonomically changing flags between the first and second call to `should_set_client_emulation_mode_flags` which changes its decision. 

Alternatively `should_set_client_emulation_mode_flags` could be implemented as a set once property.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27765#pullrequestreview-3334091882
PR Review Comment: https://git.openjdk.org/jdk/pull/27765#discussion_r2428057465
PR Review Comment: https://git.openjdk.org/jdk/pull/27765#discussion_r2428065386