RFR: 8243961: ForceNUMA and only one available NUMA node fails assertion on Windows

[Thomas Schatzl]

Hi,

On 29.04.20 14:28, Kim Barrett wrote:
> Please review this Windows-specific change to the initialization of
> UseNUMAInterleaving.
> 
> If UseNUMAInterleaving is true but is run on a version of Windows that
> doesn't support NUMA APIs or on a single-node platform, bad things can
> happen.  Ordinarily that would cause UseNUMAInterleaving to be forced
> off.  But if UseNUMA and ForceNUMA are also true, then sometime later
> in the argument initialization UseNUMAInterleaving will be forced back
> on, even though the supporting environment and data structures may not
> be correct for that.
> 
> We solve this by making the forcing of interleaving off sticky (by
> setting "ergonomically"), so the later possible default update will be
> suppressed.
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8243961
> 
> Webrev:
> https://cr.openjdk.java.net/~kbarrett/8243961/open.00/
> 
> Testing:
> mach5 tier1-3
> 
> mach5 testing on Windows with explict +UseG1GC +UseNUMA +ForceNUMA and
> each of +/-/(default)UseNUMAInterleaving.
> 
> TestUseNUMAInterleaving fails for some of those test configurations on
> non-NUMA hardware, because the test expects UseNUMAInterleaving to be
> enabled if UseNUMA is enabled.  As the test failure can only happen
> with +ForceNUMA, that configuration doesn't seem to otherwise lead to
> other problems, +ForceNUMA doesn't seem to be a tested configuration,
> and ForceNUMA is going away (JDK-8243628), we'll not worry about that
> failure.

Change is okay, but what do you think about always disabling UseNUMA 
regardless of ForceNUMA on Windows instead?

There does not seem to be a code path in the windows OS files that acts 
on UseNUMA. For NUMA related methods it returns default values, so any 
path in the GCs will just do nothing or act on useless default values 
from the os layer and do weird things.

UseNUMAInterleaving is completely separate from UseNUMA functionality 
anyway (although "UseNUMA" is misleading at least to me, but that's 
another discussion).

There is the problem then that probably many people enable UseNUMA to 
get UseNUMAInterleaving, but that could be handled in a windows specific 
way too. I.e. when -XX:+UseNUMA and -XX:+/-ForceNUMA is set, disable 
UseNUMA and enable UseNUMAInterleaving.

That sounds much easier to understand to me than the current change.

Some collectors (Z, Shenandoah) will set UseNUMA, but this evaluation is 
before os::init_2 so above idea would do the right thing as neither have 
any special UseNUMA path. I.e. both actually seem to want 
UseNUMAInterleaving. Shenandoah explicitly says so, so actually changing 
them to enable UseNUMAInterleaving instead of UseNUMA would be good too imo.

On non-Windows there will be no difference to now.

Thomas