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 at oracle.com
Mon Aug 22 08:02:11 UTC 2016
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
> 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
> 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.
> benchmark runs, jprt
Looks good to me.
> 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.
More information about the hotspot-gc-dev