On 3/02/2014 11:54 PM, Alan Bateman wrote:
On 03/02/2014 13:18, Chris Hegarty wrote:
Hi,
An old issue has resurfaced because of a change in AWT. AWT, now, on
Mac OS X, attaches a system graphics thread to the running VM, using
JNI_AttachCurrentThread. This change can result in a NPE, if a
security manager is installed, and the security manager tries to print
the name of the current thread.
In this case, attaching a thread to the VM, the j.l.Thread
instance/oop is created by the VM in allocate_threadObj(), and then
its constructor is run. At this point almost everything has been
created for the thread, jni env, etc, so it can query currentThread()
to retrieve itself. (Note: this is unusual. Typically the thread
running the j.l.Thread constructor is not itself.) Since the
j.l.Thread oop was allocated directly by the VM, its fields, other
than those directly set by allocate_threadObj(), are not initialized.
The call out from Thread.init to the security manager is problematic
as the partially constructed thread can be retrieved through
Thread.currentThread. Some of our internal tests run into a problem
when the security manager tries to print the name of the thread, i.e.
NPE.
Clearly there are other concerns of accessing a partially constructed
thread, not just the thread name, but it seems reasonable to simply
move the setting of the name to the beginning of the init() method.
I propose the following change for JDK 9, with the intention of backport
exactly to JDK 8. Long term this should be revisited in JDK 9.
As a short term fix then this looks okay to me. An alternative might be
for getName to return the empty String if called before the name is set.
I think the current fix is preferable as it returns the correct name
rather than just side-stepping the NPE.
I assume that part of re-visiting later will be to update API docs
(maybe JNI spec too) to allow for initialization on the "current thread"
when attaching as it can't be guaranteed to be fully initialized at this
point.
What API docs do you think need updating? The revisiting would be to try
and find a complete solution to this initialization problem.
Unfortunately it is a catch-22: only an attached java thread can execute
Java code; initialization of the Thread object during the attach has to
execute Java code. Some possible solutions are suggested in a linked CR,
but none of them are ideal.
Cheers,
David
-Alan.
PS: We should probably change the bug synopsis to make it clearer what
this issue is about now.
