JDK-8189942 : Add option for Implementation JEP 312: Thread-local handshake
  • Type: CSR
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 10
  • Submitted: 2017-10-25
  • Updated: 2017-11-02
  • Resolved: 2017-11-01
Related Reports
CSR :  
JDK-8189941 - Implementation JEP 312: Thread-local handshake
Relates :  
JDK-8185640 - JEP 312: Thread-Local Handshakes
Description
Summary
-------
Introduce an option to control use of the new Thread-local handshake safepoint mechanism introduced by JEP 312.

Problem
-------
JEP 312 introduces a new safepoint mechanism: Thread-local handshakes. To opt-out on supported platforms of using this new mechanism a new VM flag is required.

Solution
--------
Add a new product option ThreadLocalHandshakes (default true) to allow users to select the new safepoint mechanism.

Specification
-------------

Complete code is at: http://cr.openjdk.java.net/~rehn/8185640/

    +  product_pd(bool, ThreadLocalHandshakes,                                   \
    +          "Use thread-local polls instead of global poll for safepoints.")  \
    +          constraint(ThreadLocalHandshakesConstraintFunc,AfterErgo)         \
    +                                                                            \
Comments
No this is still a -XX flag. The product_pd means it is a product flag with a platform dependent initial setting.
02-11-2017
Moving to approved.
01-11-2017
Assuming "product_pd" means "-X" flag, changing the scope to "JDK."
01-11-2017
Thank you. Agree with product_pd flag as better.
31-10-2017
This flag matches how the functionality is referred to in the code. There was an alternate suggestion of UseThreadLocalPoll which might be better, but this one is fine also. We don't really want people using this flag. In summary, we like the flag name.
31-10-2017
In review thread [~dholmes] suggested that a product_pd flag would be better. I took this suggestion and updated CSR with that change.
31-10-2017
If the flag should have limited use and not really expected to be used often (as an -XX flag rather than a -X) flag, I'll vote to approve the request in its current state, but I think a different name would be more suggestive as to what the flag is doing. Please finalize the request for the second phase of review once the name of the flag is determined.
30-10-2017
The aim here is not really to provide a selection of mechanisms to be chosen at will, but to move to the new mechanism transparently when it applies, yet provide a way to go back to the old, in case there are any issues encountered. IIUC.
30-10-2017
The flag is: -XX:+ThreadLocalHandshakes So it's XX flag. Enumeration is not possible for flags. But I agree in theory that would be better. EDIT: I see now there is an: ccstrlist that act as an enumeration. But it require manually parsing. So it's just a sting. The option name ThreadLocalPoll might be better?
30-10-2017
I'm moving this request to Provisional state. However, I suggest considering some alternative names for the flag before the request is finalized for the second phase of CSR review. The name "ThreadLocalHandshakes" standing alone does not indicate what kind of functionality the flag is affecting, in contrast a name like "SafepointMechanism". Are more than two safepoint implementations possible in the future? If so, a non-boolean flag with an enum of options would prevent the additional of other flags in the future, SafepointMechanism=ThreadLocal, SafepointMechanism=Traditional, etc..
30-10-2017
Setting Scope to JDK for a -X flag; if the flag is changed to -XX, Scope should be set to Implementation.
30-10-2017