How does the openjdk deal with stack lock's recursive exit
David Holmes
David.Holmes at oracle.com
Thu Jun 16 19:06:02 PDT 2011
The synchronization code is rather complicated in its entirety but
basically:
- when you first lock a monitor you will get a BasicLock with a non-null
displaced header
- subsequent recursive locks create BasicLocks with null displaced headers
A chain of BasicLock objects is formed (in the simplest case implicitly
by the frames in the call chain).
An unlock processes the BasicLock at the end of the chain (the most
recent lock action). If the displaced header is null it was a recursive
lock and there is nothing to do. Eventually an unlock must find a
BasicLock where the displaced header is not null, and that is when the
actual unlock occurs.
Hope that makes things clearer. This is an extremely complicated part of
the VM.
Cheers,
David Holmes
wei he said the following on 06/17/11 01:07:
> hi,
> I read the synchronizer.cpp of the openjdk, and find it when use stack
> lock, if the current thred recursive enter the stack lock, the stack
> lock's displace header will be set null, and when the current thread
> want to release the stack lock(i think by call the function slow_exit,
> which intrun call the fast_exit), but i find that in the fast exit, when
> hotspot find that stack lock's displace header is null, it will
> donothing, just return. so my question is if this thread has recursive
> exit this stack lock completely, and evry time the fast_exit function do
> nothing except find the lock's displace header is null, how can this
> lock's state return to be neutral? by the way, the code i read is
> openjdk-7-ea-src-b136-31_mar_2011.
>
> Any suggestion is appreciated, thks.
More information about the hotspot-runtime-dev
mailing list