RFR (S): Parallel AlwaysPreTouch

Roman Kennke rkennke at redhat.com
Mon Oct 10 13:31:25 UTC 2016


Am Montag, den 10.10.2016, 15:05 +0200 schrieb Aleksey Shipilev:
> On 10/10/2016 02:55 PM, Roman Kennke wrote:
> > 
> > Some little comments:
> > - Why do we need our own flag? Can't we simply use the
> > +AlwaysPreTouch
> > flag?
> 
> Ah, I was about to explain that in comments, but forgot. VirtualSpace
> code has this nasty thing:
> 
> static bool commit_expanded(char* start, size_t size, size_t
> alignment,
> bool pre_touch, bool executable) {
>   if (os::commit_memory(start, size, alignment, executable)) {
>     if (pre_touch || AlwaysPreTouch) {
>       pretouch_expanded_memory(start, start + size);
>     }
>     return true;
>   }
> 
> ...notice AlwaysPreTouch is unconditionally checked. This will get
> memory touched during the initial storage allocation, even before
> we've
> got a chance to wind up gang workers to parallelize it. So, if we
> want
> to bypass this behavior, there are two options:
>  a) Create our own VirtualSpace (like G1 is doing), and manage memory
> by
> ourselves;
>  b) Turn off AlwaysPreTouch, substitute it with a flag, and do this
> little thing on our own.
> 
> I think (b) is much less hassle.
> 
> > 
> > - 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?
> 
> The flag is coming from G1 changes, it seems we can leverage that.
> Also,
> regions are not yet initialized at this point, and it would seem more
> straightforward to do this on storage memory.

Ah, ok, that explains it. Ok to go then! Maybe add comments in code..?

Roman



More information about the shenandoah-dev mailing list