Question about thread initialization

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.
> 
> JVM_StartThread calls new JavaThread()
>    JavaThread::JavaThread() calls os::create_thread()
>      os::create_thread() starts the new thread and waits for the
> handshake, then returns
> 
> Back in JVM_StartThread, 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::record_stack_base_and_size(). 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
> record_stack_base_and_size() before calling Thread::run(), right at
> the start of the native entry function (thread_native_entry 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