RFR: 8286830: ~HandshakeState should not touch oops

[David Holmes]

On Mon, 30 May 2022 10:25:08 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Since the JT after the state "is_exiting" still uses oops and interacts with Java, it's no where close to be hidden.

Setting is_exiting is the start of hiding the thread from the rest of the system. The only interaction with "Java" after that is ensure_join to perform the ObjectMonitor notification and to mark the Thread's own Java state as "dead". This is the point at which this thread is dead to Java code and thus "hidden". The is_exiting state should be a gate for any JVMTI callbacks and JFR events as they don't apply to "terminated" threads - for JFR we call on_thread_exit shortly after setting the is_exiting state and just before that we could still post monitor exit events).

The thread must participate in safepoints up until its last oop-touch, which means after barrier_set->on_thread_detach() it does not need to participate in safepoints - and shouldn't hit any more polling points after that anyway.

A handshake with a thread is only needed to interact with that thread in some way and we don't interact with "terminated" threads - so no handshakes needed.

We have a two-stage termination sequence (is_exiting then terminated) precisely because the vast majority of interactions with a thread cease after is_exiting, and everything after "is terminated". So we're really only discussing the relatively small window between those two points. I'm arguing that there is no need to process handshakes from the start of that Window, rather than from the end. The basic sequence is:

1. set is_exiting -> thread is no longer of interest to JVM TI or any handshakes related to JVM TI or Java code
2. set java.lang.Thread status to TERMINATED -> thread is now dead to Java
3. JFR::on_thread_exit() -> thread is now "dead" to JFR 
4. barrier_set()->on_thread_deatch() -> no more oop interaction so no need for further safepoints
5. ThreadSMRSupport::remove_thread -> thread no longer in main ThreadsList
6. set _thread_terminated 

> You can see the comment: "These things needs to be done while we are still a Java Thread"

That comment is referring to the thread destructor process where we must still be seen to be a JavaThread and not a basic Thread - ie those actions must happen before the end of ~JavaThread. (We had issues where we made calls to virtual functions from ~Thread which didn't dispatch correctly.)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8795