Fix interaction of VMInit and ThreadStart events.
Real world agents require that one is able to create, and run, new
threads while the VMInit event is still being executed. Further, these
require that ThreadStart events can occur concurrently with the VMInit
event. This CL enables this behavior and adds a test for the
interaction of these two events.
Test: ./test.py --host -j50
Bug: 62821960
Bug: 34415266
Change-Id: I305f1ce3f1df9bf5a7e33027e0724f5fbac5c0f1
diff --git a/openjdkjvmti/ti_phase.cc b/openjdkjvmti/ti_phase.cc
index e8c1ca7..07cf31c 100644
--- a/openjdkjvmti/ti_phase.cc
+++ b/openjdkjvmti/ti_phase.cc
@@ -72,9 +72,16 @@
{
ThreadUtil::CacheData();
PhaseUtil::current_phase_ = JVMTI_PHASE_LIVE;
- ScopedLocalRef<jthread> thread(GetJniEnv(), GetCurrentJThread());
- art::ScopedThreadSuspension sts(art::Thread::Current(), art::ThreadState::kNative);
- event_handler->DispatchEvent<ArtJvmtiEvent::kVmInit>(nullptr, GetJniEnv(), thread.get());
+ {
+ ScopedLocalRef<jthread> thread(GetJniEnv(), GetCurrentJThread());
+ art::ScopedThreadSuspension sts(art::Thread::Current(), art::ThreadState::kNative);
+ event_handler->DispatchEvent<ArtJvmtiEvent::kVmInit>(
+ nullptr, GetJniEnv(), thread.get());
+ }
+ // We need to have these events be ordered to match behavior expected by some real-world
+ // agents. The spec does not really require this but compatibility is a useful property to
+ // maintain.
+ ThreadUtil::VMInitEventSent();
}
break;
case RuntimePhase::kDeath: