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]

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160823/19435cee/attachment.htm>