JDK-8257974 : Regression 21% in DaCapo-lusearch-large after JDK-8236926
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 16
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-12-09
  • Updated: 2021-01-20
  • Resolved: 2020-12-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 16 JDK 17
16 b30Fixed 17Fixed
Related Reports
Relates :  
JDK-8236926 - Concurrently uncommit memory in G1
Description
This regression appeared in b26 and was about the same in b27
Comments
Changeset: 38593a4f Author: Stefan Johansson <sjohanss@openjdk.org> Date: 2020-12-18 08:14:58 +0000 URL: https://git.openjdk.java.net/jdk16/commit/38593a4f
18-12-2020
I've done some investigations on this and the fact that we do uncommit concurrently with the benchmark during measurement is causing the regression. I did some JFR runs to see if I could get any better understanding of why this benchmark seems to be more affected than others, and I see a lot more "Java Monitor Blocked" blocked events with the build with concurrent uncommit. I have not dug deep into why this show up, but one theory is that the thread holding the monitor gets stalled because of the uncommit and then no other threads can do progress either. To minimize the risk of this occurring we can be a bit less aggressive when it comes to uncommitting the memory. The proposed fix that I'm about to send out delays the first uncommit 100ms after the GC shrinking the heap and then each new invocation of the task will be delayed 10ms. The chunk size that we uncommit is also reduced from 256m to 128m to further limit the impact of uncommit on application threads. We have also had discussions around using madvise to hand back the memory to the OS. We've done some small experiments using both MADV_DONTNEED and MADV_FREE. MADV_DONTNEED shows some pretty promising results, and could possibly be used as a replacement for the current os::pd_uncommit_memory() for Linux. But we need to do more investigations and we have JDK-8210709 open for this.
17-12-2020