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 at oracle.com
Tue Aug 23 18:54:41 UTC 2016
In the original code did you ever see this assertion failing? Or would
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);
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
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev