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

[Thomas Schatzl]

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