Restrictions for lock coarsening?

Dave Dice Dave.Dice at Sun.COM
Sun Jan 4 18:46:31 PST 2009


On 2009-1-4, at 6:09 PM, Clemens Eisserer wrote:

> Hi Dave,
>
> Thanks again for taking the time to anwer my neverending locking  
> questions ;)
>
>> Locks and monitors have precisely the same semantics with respect  
>> to the
>> java memory model.
> Glad to hear that :)
>
>> Coarsening is a bit tricky.   IIRC we only coarsen abutting or nearly
>> abutting critical sections under the same lock but I don't think  
>> we'll hoist
>> the critical section outside of a loop.   Coarsening is, for the  
>> most part,
>> an optimization that attempts to avoid CAS / lock:cmpxchg which  
>> have a
>> _local latency penalty.   In addition it gives the JIT more  
>> latitude in the
>> fact of the memory model (we can avoid spilling variables back to  
>> memory
>> with larger critical sections).   That having been said,  you don't  
>> really
>> want to coarsen critical sections if there's contention.  (Recall  
>> that we
>> can capture code that's _not part of a critical section inside a  
>> coarsened
>> section, thus artificially lengthening the critical section).    
>> Ideally we'd
>> have runtime feedback and decoarsen contended critical sections but  
>> that's
>> not implemented as of today, so instead the mechanism is fairly
>> conservative.
> 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?
>
> 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 ;)

Hi Clemens,


Process designers finally seem aware of the issue and the trend is  
toward some improvement.

Regards
Dave



>
>
> Thanks again, Clemens




More information about the hotspot-runtime-dev mailing list