RFR: 8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet [v23]

[Y. Srinivas Ramakrishna]

On Wed, 8 Oct 2025 20:08:25 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> ShenandoahHeap::initialize() makes use of SoftMaxHeapSize.  If the SoftMaxHeapSizeConstraintFunc is handled "after memory init", the value of SoftMaxHeapSize is not yet available when we try to use it.
>> 
>> I welcome an alternative approach if you have any ideas.
>
> Did all tests pass, in particular `TestSoftMaxHeapSize`? The test now happens earlier. I am not sure why the value itself isn't available before, like you say. I am guessing you want to check the value after whatever adjustments have been made in `initialize()`? The value of the flag should be available already, irrespective of when the constraints check is done.
> 
> 
> enum class JVMFlagConstraintPhase : char {
>   // Will be validated during argument processing (Arguments::parse_argument).
>   AtParse         = 0,
>   // Will be validated inside Threads::create_vm(), right after Arguments::apply_ergo().
>   AfterErgo       = 1,
>   // Will be validated inside universe_init(), right after Metaspace::global_initialize().
>   AfterMemoryInit = 2
> };

In particular, in its current form, the test asks for the value to be <= MaxHeapSize, and ergo merely arranges to set it to MaxHeapSize, rendering any subsequent adjustments in `initialize()` to be not tested. (That in itself is perhaps OK, but we should probably check that other GCs are ok with moving the constraints check earlier. In particular, zGC adjusts the value in its initialize() and might _want_ the check later after its adjustments are done.)


GCArguments::initialize_heap_flags_and_sizes():
...
  if (FLAG_IS_DEFAULT(SoftMaxHeapSize)) {
    FLAG_SET_ERGO(SoftMaxHeapSize, MaxHeapSize);
  }
...



ZArguments::initialize_heap_flags_and_sizes():
...
  if (!FLAG_IS_CMDLINE(MaxHeapSize) &&
      !FLAG_IS_CMDLINE(MaxRAMPercentage) &&
      !FLAG_IS_CMDLINE(SoftMaxHeapSize)) {
    // We are really just guessing how much memory the program needs.
    // When that is the case, we don't want the soft and hard limits to be the same
    // as it can cause flakiness in the number of GC threads used, in order to keep
    // to a random number we just pulled out of thin air.
    FLAG_SET_ERGO(SoftMaxHeapSize, MaxHeapSize * 90 / 100);
  }
...


I'm not convinced the change above to move the constraints check sooner is needed in order to _use_ the value of SoftMaxHeapSize in `ShenandoahHeap::initialize()`.

What's the error you see without this change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2414936050