Bug ID: JDK-8172969 JVMTI spec: GetCurrentThread may return NULL in the early start phase

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 10	JDK 9
10Fixed	9 b159Fixed

It was identified in the review of 8172261 that the GetCurrentThread may return NULL during the early start phase. This issue existed with the normal start phase in the initial JVM TI implementation (JDK 1.5).
Now the GetCurrentThread is Ok to call during the normal start phase as the VMStart event is shifted to the point where the java.base is fully initialized. But now the early VMStart event is at the same point where the VMStart was in all previous releases.
The JVM TI spec needs an update to say that the GetCurrentThread may return NULL in the early start phase when the java.lang.Thread class has not been initialized yet.

The suggested patch is: diff -r 28888f4d8e05 src/share/vm/prims/jvmti.xml --- a/src/share/vm/prims/jvmti.xml Sun Feb 12 20:21:31 2017 -0500 +++ b/src/share/vm/prims/jvmti.xml Sun Feb 12 23:19:36 2017 -0800 @@ -1486,6 +1486,10 @@ <description> Get the current thread. The current thread is the Java programming language thread which has called the function. + The function may return <code>NULL</code> in the start phase if the + <internallink id="jvmtiCapabilities.can_generate_early_vmstart"> + <code>can_generate_early_vmstart</code></internallink> capability is enabled + and the <code>java.lang.Thread</code> class has not been initialized yet. <p/> Note that most <jvmti/> functions that take a thread as an argument will accept <code>NULL</code> to mean @@ -1498,7 +1502,7 @@ <param id="thread_ptr"> <outptr><jthread/></outptr> <description> - On return, points to the current thread. + On return, points to the current thread, or <code>NULL</code>. </description> </param> </parameters> @@ -14735,6 +14739,11 @@ Clarified can_redefine_any_classes, can_retransform_any_classes and IsModifiableClass API to disallow some implementation defined classes. </change> + <change date="12 February 2017" version="9.0.0"> + Minor update for GetCurrentThread function: + - The function may return NULL in the start phase if the + can_generate_early_vmstart capability is enabled. + </change> </changehistory> </specification>

13-02-2017

I've updated this suggested fix according to the Dan's comment below: - Add the following line to the GetCurrentThread spec: "The function may return NULL in the start phase if the can_generate_early_vmstart capability is enabled and the java.lang.Thread class has not been initialized yet." - In the Parameters section replace: "On return, points to the current thread." with: "On return, points to the current thread, or NULL."

09-02-2017

The parameters section of GetCurrentThread() looks like this: thread_ptr | jthread* | On return, points to the current thread. ________ | ______ | Agent passes a pointer to a jthread. On return, the ________ | ______ | jthread has been set. The object returned by ________ | ______ | thread_ptr is a JNI local reference and must be managed. I think the wording in this section needs to be adjusted for the possibility of *thread_ptr being set to NULL with no JVM/TI error being returned.

09-02-2017

Relates :	JDK-8146454 - Add support for module aware agents
Relates :	JDK-8172261 - [JVMTI] Specification for early VM start event needs to lower expectations in relation to class loading