synchronization on non-escaping objects

[Vladimir Kozlov]

 >
 >     private final char X = 'x';
 >        synchronized (this) {
 >            return X;
 >        }

Since X field is final C2 optimizer returns value 'x'
without loading it from object's field:

059     MOV    EAX,#120

There are no operations left between acquiring and releasing the lock.
Also no instructions are generated for MEMBARs you pointed -
look on instructions address. They are printed for debugging purpose.
They are empty because they are not needed for an object which
is biased locked for the current thread. And slow code has CMPXCHG
which is treated as MEMBAR.

Vladimir

Vijay Kandy wrote:
> Vladimir,
> 
> Thanks for the reply. I didn't think of the implicit 'this' input
> parameter that escapes. It makes sense now.
> 
> If I could ask one more question - what does it mean when there are no
> instructions between MEMBAR-acquire and MEMBAR-release as in B3? I
> mean, what's the purpose of acquire/release in this scenario:
> 
> 051   B3: #	B8 B4 <- B7 B6 B2 B14  Freq: 1
> 051   	MEMBAR-acquire (prior CMPXCHG in FastLock so empty encoding)
> 051   	MEMBAR-release ! (empty encoding)
> 051   	MOV    ECX,#7
> 056   	AND    ECX,[EBP]
> 059   	CMP    ECX,#5
> 05c   	Jne,s  B8  P=0.000001 C=-1.000000
> 
> Regards,
> Vijay
> 
> On Thu, Nov 19, 2009 at 1:03 PM, Vladimir Kozlov
> <Vladimir.Kozlov at sun.com> wrote:
>> 'this' object is input parameter for getX() so it escapes
>> and full synchronization code is generated. What you see in
>> B1 and B2 is biased locking code which checks if the object
>> is locked by current thread if not it goes to slow path.
>>
>> When you synchronize on 'new Object()' - it does not escape
>> (no other threads can access it) so synchronization code and
>> the object is eliminated.
>>
>> Vladimir
>>