Tuning ShenandoahGC with 420 GB heaps

[Aleksey Shipilev]

On 3/5/19 10:51 AM, Jeroen Borgers wrote:
> Thanks for your remarks. In addition to Edwins findings:
> 1.1 AlwaysPreTouch seems to be on while reported as off, as shown in 'ps' and in logfile it says
> (line 12:)

Right. Sorry, my bad, that's Shenandoah reverting dropping AlwaysPreTouch and enabling
ShenandoahAlwaysPretouch specifically. It needs to be that way to avoid hitting serial pretouch code
that would wreck up NUMA interleaving.

> 3. Right, sudden high allocation rates are a problem. Getting more memory will take time. We might
> be able to throttle the load somewhat.

Yes, either throttle the load (for example, beef up pacing threshold), or maybe beef up the
ConcGCThreads?

> Like my colleague found, (transparent) huge pages do not seem to be utilized fully. I see in the log
> file:
> Memory: 4k page, physical 528157524k(460445396k free), swap 2097148k(1463356k free)  
> and on line 12:
> Parallel pretouch 13440 regions with 2097152 byte pages
> So it seems to use both 4kB and 2MB pages. The latter area is only 26 GB.
> We don't understand this nor how to solve it. Suggestions very welcome.

This is Shenandoah bug! Argh. Tracked here:
  https://bugs.openjdk.java.net/browse/JDK-8220153

-Aleksey