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

[Jon Masamitsu]

On 08/24/2016 12:39 AM, Mikael Gerdin wrote:
> 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,

  I missed the point of this  change.  Thanks for helping
me make sense of it.

Jon

>
> /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
>>