RFR: Enable NUMA by default

[Aleksey Shipilev]

Patch:

diff -r 34af82382067 src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp
--- a/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp   Fri Oct 12 14:05:44 2018 +0200
+++ b/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp   Tue Oct 16 09:27:42 2018 +0200
@@ -72,4 +72,12 @@
   }

+  // Enable NUMA by default. While Shenandoah is not NUMA-aware, enabling NUMA makes
+  // storage allocation code NUMA-aware, and NUMA interleaving makes the storage
+  // allocated in consistent manner (interleaving) to minimize run-to-run variance.
+  if (FLAG_IS_DEFAULT(UseNUMA)) {
+    FLAG_SET_DEFAULT(UseNUMA, true);
+    FLAG_SET_DEFAULT(UseNUMAInterleaving, true);
+  }
+
   FLAG_SET_DEFAULT(ParallelGCThreads,
                    Abstract_VM_Version::parallel_worker_threads());


Backing story: UseNUMA tries to enable Hotspot infrastructure for NUMA, if available. It would turn
off if NUMA is not supported (ForceNUMA does force it, but not UseNUMA). JEP 163 was targeting to
enable it by default, but it is seemingly abandoned. ZGC does enable NUMA with the similar code as
above. The difference for Shenandoah is that allocation code is not NUMA-aware, so we do the next
best thing: interleaving all memory at once. (This can be simulated now with -Xms -Xmx
-XX:+AlwaysPreTouch that pretouches all memory by all workers, but plain interleaving seems more
precise).

Performance tests on my TR 2950X running in NUMA mode shows significant run-to-run variance
improvements on Compress, CryptoRsa, CryptoSignVerify, Derby, Serial and XmlValidation.
The improvements are good: average goes up +5%. In CryptoRsa case, average goes up +20%, because
variance is really bad in UMA mode there.

Testing: tier3_gc_shenandoah (NUMA-enabled TR, UMA i7)

Thanks,
-Aleksey