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