Bug ID: JDK-8220049 Obsolete ThreadLocalHandshakes

Type: Enhancement
Component: hotspot
Sub-Component: runtime
Affected Version: 13

Priority: P4
Status: Resolved
Resolution: Fixed

Submitted: 2019-03-04
Updated: 2024-02-06
Resolved: 2019-12-11

JDK 14	JDK 15
14 b27Fixed	15Fixed

Option was introduced in JDK 10.
We are seeing many new features using handshakes for grace-periods (barrier) and doing thread-to-thread communication.
Soon turning off handshakes is not viable performance-wise.

Tests using the flag should have been updated to stop using it as part of this change.
16-12-2019
URL: https://hg.openjdk.java.net/jdk/jdk/rev/be5d924adffa User: rehn Date: 2019-12-11 14:38:48 +0000
11-12-2019
That is what I tried todo in: - Secondly, remove flag: http://cr.openjdk.java.net/~rehn/8220049/draft/ (found I more mentioning of the flag, updated in-place)
05-12-2019
This is all still very confusing. When a flag is obsoleted it is supposed to be removed from globals*.hpp etc. Then actual removal of the expired flag simply involves deleting the entry from the flag table. At the moment this flag claims to be obsolete, and it apparently can't have its default value changed, yet the flag remains mentioned all over the code! Is there not some further cleanup we can do for 14 to make this actually look like it has been obsoleted?
05-12-2019
The flag is not needed since we know in compile-time which path the platform should use based on THREAD_LOCAL_POLL is defined or not. ARM32 have not defined THREAD_LOCAL_POLL and so the flag have no effect. Even if you change the flag to default true, since it have not defined THREAD_LOCAL_POLL it will still be false. THREAD_LOCAL_POLL defines if this platform supports handshakes or not. ThreadLocalHandshakes is/was a way to opt-out if there was an issue. No issues have been reported AFAIK. Therefore we remove the option to opt-out. (why I waited was that this change would be easier to make if arm32 supported THREAD_LOCAL_POLL)
05-12-2019
That webrev looks good to me. But it still seems to me either this should be done for 14, or else the flag table must be updated so that the flag is not obsoleted until 15.
05-12-2019
"obsoleting" a flag means replacing its use by its default value and then cleaning up the code (including. removing the flag from globals*.hpp). If some platforms need the "flag" value to be true and others false then you can't really do that. Seems to me the first step here is that all platforms have to support ThreadLocalHandshakes==true as a default.
04-12-2019
It's an 'implementation detail' nothing that an user should change. As soon as arm32 have support for locals polls the plan is to remove all global path code. But to remove that code the flag needs to be obsoleted. (keeping the flag because code we want to remove is still there, becomes a circular argument :) )
04-12-2019
Sorry but I'm very confused about this. We have ./cpu/aarch64/globals_aarch64.hpp:define_pd_global(bool, ThreadLocalHandshakes, true); ./cpu/arm/globals_arm.hpp:define_pd_global(bool, ThreadLocalHandshakes, false); ./cpu/ppc/globals_ppc.hpp:define_pd_global(bool, ThreadLocalHandshakes, true); ./cpu/s390/globals_s390.hpp:define_pd_global(bool, ThreadLocalHandshakes, true); ./cpu/sparc/globals_sparc.hpp:define_pd_global(bool, ThreadLocalHandshakes, true); ./cpu/x86/globals_x86.hpp:define_pd_global(bool, ThreadLocalHandshakes, true); ./cpu/x86/globals_x86.hpp:define_pd_global(bool, ThreadLocalHandshakes, false); ./cpu/zero/globals_zero.hpp:define_pd_global(bool, ThreadLocalHandshakes, true); so to remove ThreadLocalHandshakes flag we have to hard-wire true or false based on the platform. But if we can have a true or false path then we are supporting both and so removing the flag makes no sense to me. ???
04-12-2019
To answer my own question: this was supposed to be obsoleted in JDK 14 but it has not been! So the flag table in arguments.cpp is wrong and needs to be fixed in 14: ./share/runtime/arguments.cpp: { "ThreadLocalHandshakes", JDK_Version::jdk(13), JDK_Version::jdk(14), JDK_Version::jdk(15) }, The actual handling of the ThreadLocalHandshakes flag in 14 is very confusing. It seems that on x86_64 you cannot turn it off, but I can't see what code actually achieves that - unless the fact we list it as obsoleted in 14 means the attempt to set the flag to false fails. Regardless this needs to be fixed in 14. Either the flag should be deleted from the code as per the obsoletion state of the flag, or else the flag table must be updated.
04-12-2019
To remove it think we need something like: - First change Linux x86 to use TLH (RedHat are on-board) (This is the only platform which supports TLH but have it off) http://cr.openjdk.java.net/~rehn/8220049/prerequisite/ - Secondly, remove flag: http://cr.openjdk.java.net/~rehn/8220049/draft/ If the platform supports THREAD_LOCAL_POLL we have handshakes enabled. Only arm32 do not yet have THREAD_LOCAL_POLL, we need that old global poll path for it. What you think [~dholmes] ?
04-12-2019
Was this Obsoleted in 14? Actual removal of flags is handled under a single request at the start of the release cycle: JDK-8231559
03-12-2019
Thanks for doing this. It would help simplify G1's write barrier as well: JDK-8226731.
02-08-2019

Relates :	JDK-8235811 - Partially undo changes to Graal and AOT introduced in 8220049.
Relates :	JDK-8235965 - Tests using ThreadLocalHandshakes need to stop using it as it no longer exists
Relates :	JDK-8226731 - Remove StoreLoad in G1 post barrier

JDK-8220050 :	Deprecate -XX:-ThreadLocalHandshakes - Resolved
JDK-8220051 :	Remove global safepoint code - Resolved