RFR (M): 8157952: Parallelize Memory Pretouch
Jon Masamitsu
jon.masamitsu at oracle.com
Thu Sep 8 16:52:01 UTC 2016
On 09/08/2016 04:47 AM, Thomas Schatzl wrote:
> Hi Jon,
>
> a new webrev is available at http://cr.openjdk.java.net/~tschatzl/815
> 7952/webrev.1/ (full) and http://cr.openjdk.java.net/~tschatzl/8157952/
> webrev.0_to_1/ (diff).
Looks good.
>
> Testing:
> jprt, local testing
>
> On Wed, 2016-09-07 at 14:37 -0700, Jon Masamitsu wrote:
>> Thomas,
>> http://cr.openjdk.java.net/~tschatzl/8157952/webrev/src/share/vm/gc/g
>> 1/g1_globals.hpp.frames.html
>> Could we change G1PreTouchChunkSize to PreTouchChunkSize? It
>> seems like something we would want to do for other GC's at some
>> point.
> I changed it to PreTouchParallelChunkSize for now.
That's fine.
>
>> http://cr.openjdk.java.net/~tschatzl/8157952/webrev/src/share/vm/gc/s
>> hared/workgroup.hpp.frames.html
>>
>> 64 _gc_id(Universe::is_fully_initialized() ? GCId::current_raw()
>> : 0)
>> What prompted the above change?
> The problem is that GCId::current_raw() is retrieved from the current
> NamedThread data structure. At initialization we are not running in a
> NamedThread. I found though that passing a GcId::undefined() here
> (using an additional constructor) allows logging at startup.
>
> This version is much nicer now. Thanks again for pushing me about that.
Yes, I like it.
>
>> http://cr.openjdk.java.net/~tschatzl/8157952/webrev/src/share/vm/gc/g
>> 1/g1PageBasedVirtualSpace.cpp.frames.html
>>
>> I don't think there is anything G1 specific about class
>> G1PretouchTask. Could it be renamed PretouchTask and put into its
>> own file for easier reuse? If you think that is premature, ignore
>> this comment.
> As mentioned earlier, it takes much more work than that to be reusable,
> particular for parallel gc.
>
>> Pretouch() allows for the case where the work is done by the
>> current thread (only 1 chunk or null pretouch_gang).
>> 259 void G1PageBasedVirtualSpace::pretouch(size_t start_page,
>> size_t size_in_pages, WorkGang* pretouch_gang) {
>> Pretouching is so slow that I would not think it made a difference if
>> parallel worker were used instead of the current thread. Simpler to
>> just always require a gang and use 1 worker in the degenerate case?
> Fixed.
Thanks.
Reviewed.
Jon
>
> Thanks,
> Thomas
>
More information about the hotspot-gc-dev
mailing list