Question about thread initialization (original) (raw)

David Holmes david.holmes at oracle.com
Fri Oct 12 10:39:06 UTC 2018

Hi Thomas,

On 12/10/2018 6:18 PM, Thomas Stüfe wrote:

Hi all,

a small question. JVMStartThread calls new JavaThread() JavaThread::JavaThread() calls os::createthread() os::createthread() starts the new thread and waits for the handshake, then returns Back in JVMStartThread, we call JavaThread::prepare(), which adds the new thread to the Threads list. By that time, the new thread is already running, but how far it has gotten is unknown.

Right - though the new thread can't enter run() until after it has been prepared and "started". There are two parts to the handshake:

 Parent thread             New Thread
start new Thread
wait for new thread
                          signal parent
                          wait for parent
prepare new thread
"start" new thread
signal new thread
                           run()

The new thread's stack dimensions are set from within Thread::run() (for some reason, every child class does this on its own?) by calling Thread::recordstackbaseandsize(). So, after the handshake with its parent thread. Why?

Good question. Undoubtedly historical. :)

This means we have a little race: in the Threads list there may be threads which have been just created and Thread::run() did not yet get around to set the stack size. In tests I stumbled over this, very rarely, when iterating Threads to check the stack sizes.

Hmmm. Threads that are still _thread_new should really be invisible until more fully initialized. How exactly were you iterating the threads? This might be an oversight in the related APIs.

Is there any reason why we could not just call recordstackbaseandsize() before calling Thread::run(), right at the start of the native entry function (threadnativeentry in the case of Linux)?

Have you tried it? :)

I can't immediately see why this can't happen in the thread_native_entry. It's possible there was once a dependency with something in thread preparation etc, but that's just speculation on my part.

Am I missing something here?

I guess we will find out :)

Cheers, David

Thanks,

Thomas

More information about the hotspot-runtime-dev mailing list