Hi Daniel, Please correct me if I‘m wrong but the spec change will touch post-JDK8 releases only?
Sergey Nazarkin > On Jul 9, 2020, at 19:25, Daniel D. Daugherty <[email protected]> > wrote: > > On 7/9/20 9:07 AM, Jaroslav Bachorík wrote: >> Hello, >> >> Recently, after backporting JDK-8233197 to JDK8u I received a report >> from Sergey Nazarkin (cc) that the backport broke JVMTI spec basically >> emitting JVMTI_EVENT_THREAD_START events in primordial phase while the >> spec states that it should be emitted only in either start or live >> phase. >> >> But if I am reading this correctly >> (https://hg.openjdk.java.net/jdk8u/jdk8udev/hotspot/file/02b4fd2f9041/src/share/vm/prims/jvmtiEventController.cpp#l418) >> the spec is also violated there. >> >> EARLY_EVENT_BITS are including THREAD_START_BIT and it is not filtered >> out by THREAD_FILTERED_EVENT_BITS so it seems perfectly valid for >> JVMTI_EVENT_THREAD_START to appear during PRIMORDIAL phase. >> >> So I would like to get clarification before going in and start >> tinkering with the JVM initialization code order. >> >> Thanks! >> >> -JB- > > Hi Jaroslav! > > It has been a long time my friend... :-) > > It looks like that change was made by this Jigsaw change: > > JDK-8072745 Re-examine JVM TI execution phases and expectations > on what is allowed in each phase > https://bugs.openjdk.java.net/browse/JDK-8072745 > > These diffs in the bug reported jumped out at me: > > @@ -1022,6 +1032,10 @@ > void JvmtiExport::post_thread_start(JavaThread *thread) { > assert(thread->thread_state() == _thread_in_vm, "must be in vm state"); > > + if (JvmtiEnv::get_phase() <= JVMTI_PHASE_PRIMORDIAL) { > + return; > + } > + > EVT_TRIG_TRACE(JVMTI_EVENT_THREAD_START, ("JVMTI [%s] Trg Thread Start > event triggered", > JvmtiTrace::safe_get_thread_name(thread))); > > @@ -1050,6 +1064,10 @@ > > > void JvmtiExport::post_thread_end(JavaThread *thread) { > + if (JvmtiEnv::get_phase() <= JVMTI_PHASE_PRIMORDIAL) { > + return; > + } > + > EVT_TRIG_TRACE(JVMTI_EVENT_THREAD_END, ("JVMTI [%s] Trg Thread End event > triggered", > JvmtiTrace::safe_get_thread_name(thread))); > > > Here's the order of phases from jvmti.h: > > /* Phases of execution */ > > typedef enum { > JVMTI_PHASE_ONLOAD = 1, > JVMTI_PHASE_PRIMORDIAL = 2, > JVMTI_PHASE_START = 6, > JVMTI_PHASE_LIVE = 4, > JVMTI_PHASE_DEAD = 8 > } jvmtiPhase; > > However, the above diffs prevent the JVMTI_EVENT_THREAD_START > and JVMTI_EVENT_THREAD_END events from being posted earlier than > the JVMTI_PHASE_START phase... Unfortunately, I can't find the > actual changeset pushed to the Jigsaw report for JDK-8072745. > > > When you look at the current JvmtiExport::post_thread_start() > and JvmtiExport::post_thread_end() functions, you can see this: > > 1: void JvmtiExport::post_thread_start(JavaThread *thread) { > 36508: if (JvmtiEnv::get_phase() < JVMTI_PHASE_PRIMORDIAL) { > 36508: return; > 36508: } > > 1: void JvmtiExport::post_thread_end(JavaThread *thread) { > 36508: if (JvmtiEnv::get_phase() < JVMTI_PHASE_PRIMORDIAL) { > 36508: return; > 36508: } > > $ hg log -r 36508 > changeset: 36508:5f9eee6b383b > user: alanb > date: Thu Mar 17 19:04:01 2016 +0000 > summary: 8142968: Module System implementation > > > So the Jigsaw integration pushed a slightly different change > than is shown in JDK-8072745. I don't know whether the fix > for JDK-8072745 evolved before being pushed to the Jigsaw > repos or whether another JBS issue was used to modify the > code after JDK-8072745 was pushed. > > Short version: The semantics of the JVMTI_EVENT_THREAD_START > and JVMTI_EVENT_THREAD_END were changed by Jigsaw, but the > JVM/TI spec was not updated to reflect those changes. > > I've filed a new bug to track this issue: > > JDK-8249158 THREAD_START and THREAD_END event posting changed > by modules without updating the spec > https://bugs.openjdk.java.net/browse/JDK-8249158 > > Dan
