Restrictions for lock coarsening?

[Tom Rodriguez]

> Well, my benchmark does execute the method in question in a loop,
> there's only one monitor in action and the benchmark is
> single-threaded so there is no contention. Could it be that coarsening
> does not occur because the synchronized method is too large or has too
> complex control flow (if/else, maybe even loops)? Or maybe coarening
> is limited to non-OSR compilation?

Coarsening won't rearrange control to create opportunities for  
itself.  The basic strategy is to look for straightline control where  
an unlock meets a lock of the same monitor.  If your loop body  
contains only one copy of your locked section then there's nothing  
coarsening can do.  If C2 chooses to unroll your loop body then you  
will end up with multiple copies which could then be coarsened.  It  
sounds like your loop body is probably too large for unrolling to  
trigger so I don't think it can help.

> In reallity there won't be contention for almost all of the use-cases,
> but the api is specified to be thread-safe and therefor there is no
> way arround synchronization. The reason why I am interested in
> coarsening is, that CAS means quite a lot of local latency - on my
> Core2Duo 50% of the total time is spent in locking. I guess the
> problem will vanish with better CAS implementations ;)
>

Hmm.  I would expect biased locking to handle your case perfectly with  
no CAS if things are as you describe.  For startup purposes biased  
locking disabled at the beginning of the VM and is enabled after about  
4 seconds.  This means that objects created during that time period  
aren't allowed to use biased locking.  Is it possible your test case  
is short enough to fall into this?  -XX:BiasedLockingStartupDelay= can  
be use to set the delay in milliseconds.  Also note that there's an  
oddity with OSR and locking where any locks that are held at the OSR  
point are inflated and end up using heavyweight locking until the lock  
is deflated.

tom