JDK-8220051 : Remove global safepoint code
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 14
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-03-04
  • Updated: 2024-02-06
  • Resolved: 2020-04-01
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 15
15 b18Fixed
Related Reports
Relates :  
JDK-8198730 - Improve detection of failure to reach a safepoint
Relates :  
JDK-8213524 - SafepointMechanism: poor method naming
Relates :  
JDK-8305236 - Some LoadLoad barriers in the interpreter are unnecessary after JDK-8220051
Relates :  
JDK-8229971 - Arm32: implementation for Thread-local handshakes
Relates :  
JDK-8264063 - Outer Safepoint poll load should not reference the head of inner strip mined loop.
Relates :  
JDK-8241363 - [JVMCI] expose SafepointMechanism::uses_thread_local_poll() to JVMCI
Comments
URL: https://hg.openjdk.java.net/jdk/jdk/rev/9c408b98e785 User: rehn Date: 2020-04-01 13:05:31 +0000
01-04-2020
Just removing global safepoint code is small, but it creates a lot of dead code paths and also removing them is much bigger task. We can remove os::get_polling_page() and friends which creates dead paths and unneeded code in all platforms. Since this work cannot be started before arm32 is fixed and if Aleksei want to remove the obvious stuff first, that's fine. We can create a second bug to tackle all dead/unneeded code paths, we probably even need a per platform task, so it's feasible to review. (e.g there are a few methods in each ad file, C1, etc.., which can be removed/cleaned up)
22-08-2019
I see. Let me assign this back to Robbin for now. And if it turns out just a clean up exercise, we are happy to do it, please assign back.
21-08-2019
Ummmm... I think there are other things that depend on the global safepoint mechanism that have to be resolved first. ARM32 is the last platform that does not support Thread-local handshakes for safepoints, but fixing that is not the same thing as the rest of the system being ready for the removal of the global safepoint mechanism. Of course, Robbin may have something in mind that I don't know about yet so let's see what he says... Minimally, I believe I have to finish with Async Monitor Deflation... :-)
21-08-2019
Arm32 is the last architecture to use this mechanism. We are working on removing the last reference to it and asked Robbin if we can take care of removing the global safepoint after we are done. Robbin advised we can do it, and that he will add some info to the bug later. If you believe you or someone else is better suited for that let me know.
21-08-2019
[~avoitylov] [~rehn] - Aleksei, why did you grab this bug?
21-08-2019