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