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 Thomas,

On 2016-08-10 23:23, 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

Looks good to me.

/Mikael

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