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