RFR (S): Parallel AlwaysPreTouch

[Roman Kennke]

Great!

Some little comments:
- Why do we need our own flag? Can't we simply use the +AlwaysPreTouch
flag?
- Instead of dividing memory into chunks, and adding another flag for
it, you could just iterate over shenandoah's regions using
ShenandoahHeapRegionSet::claim() and pretouch each region's memory?

Roman

m Montag, den 10.10.2016, 14:18 +0200 schrieb Aleksey Shipilev:
> Hi,
> 
> It is not unusual for low-latency customers with large heaps to
> enable
> -XX:+AlwaysPreTouch, that touches every page preemptively during the
> allocation (e.g. on startup). This pays the upfront cost during
> startup,
> instead of during the execution.
> 
> However, pre-touching on larger heaps may take a while, see e.g. G1
> on 1
> Tb heap reports 10 minutes (!) to init the heap [1]. So, G1 made the
> pre-touch parallel. We can do it too:
>  http://cr.openjdk.java.net/~shade/shenandoah/always-pretouch/webrev.
> 01/
> 
> On my 4-core desktop, -XX:+AlwaysPreTouch HelloWorld with 20 Gb heap
> improves 4.5s -> 1.8s. I would expect this improvement to be larger
> on
> mammoth machines.
> 
> Note that shared VM changes match the G1 changes [2], which means we
> should nicely fit during the next merge.
> 
> Thanks,
> -Aleksey
> 
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8157952
> [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/bc2c975bc342
> 
>