RFR (XS): 8155917: G1 full gc memory pretouch in free regions causes regressions in SPECjvm2008 scimark.fft, lu, sor, sparse with 9+116 on Linux-x64

[Mikael Gerdin]

Hi Jon,

On 2016-08-23 20:54, Jon Masamitsu wrote:
> Thomas,
>
> In the original code did you ever see this assertion failing?  Or would
> you expect
> it to sometimes fail?
>
> 308 assert(space->bottom() < end_of_live, "bottom: " PTR_FORMAT " should
> be < end_of_live: " PTR_FORMAT, p2i(space->bottom()), p2i(end_of_live));
>
>
> Does the "pretouch" in the description refer to the Prefetch?
>
>  324       // prefetch beyond q
>  325       Prefetch::read(cur_obj, scan_interval);


I think the word pretouch is a bit of a misnomer here since the core 
part of the change lies here:
-  !oop(space->bottom())->is_gc_marked()) {
+  (bottom == end_of_live || !oop(bottom)->is_gc_marked())) {

We short-cut the dereferencing of space->bottom() if bottom is 
end_of_live (because the region is then emtpy)
If the entire region was never paged in or has been paged out at some 
point then touching the empty object at space->bottom() to read its mark 
word would force the OS to allocate a backing page for it.

/Mikael

>
> Jon
>
> On 8/10/2016 2:23 PM, Thomas Schatzl wrote:
>> Hi all,
>>
>>   could I get reviews for this tiny change that fixes performance
>> degradation of up to 20% on various SPECjvm2008 benchmarks?
>>
>> The cause is some oversight during refactoring in JDK-8073321 that
>> causes G1 full gc pre-touch (the first page) in all free regions in the
>> heap.
>>
>> This makes the following benchmark run run much slower than before. The
>> problem seems to only occur on specific combinations of hardware and/or
>> OS (Sandybridge + OEL6) - at least on my local machine (Ivy Bridge +
>> OEL7) and other OSes (with same or different hardware) there is no
>> difference.
>> I did not really spend time to nail it down to one or the other factor,
>> but given that it is linux only, I would guess the OS is at fault here.
>>
>> Anyway, also for other reasons it is a bad idea to force paging in
>> memory in otherwise unused space for no reason.
>>
>> The fix is to not do this unintended pre-touching access during phase 4
>> of the mark-sweep gc like the code before JDK-8073321 did.
>>
>> CR:
>> https://bugs.openjdk.java.net/browse/JDK-8155917
>> Webrev:
>> http://cr.openjdk.java.net/~tschatzl/8155917/webrev/
>> Testing:
>> benchmark runs, jprt
>>
>> While trying to nail down the issue, I found a few other easy
>> improvements that might be interesting to do in the future (JDK-
>> 8163577, JDK-8163579, JDK-8163578). For the sake of keeping this fix
>> succinct, I did not add these here.
>>
>> Thanks,
>>   Thomas
>