Restrictions for lock coarsening?

[Dave Dice]

On 2009-1-8, at 6:43 PM, David Holmes - Sun Microsystems wrote:

> Christian Thalinger said the following on 01/09/09 09:33:
>> On Fri, 2009-01-09 at 08:27 +1000, David Holmes - Sun Microsystems
>> wrote:
>>> Also note, as I understand from work I did late in the Java 6  
>>> cycle, once an object has its biased revoked it remains revoked ie  
>>> it will not participate in biased-locking again. This was done to  
>>> prevent "thrashing" and it also makes things easier to reason about.
>> Looking at bulk_revoke_or_rebias_at_safepoint(), it seems you're  
>> right.
>> Even worse.  All future instances of a class cannot use biased  
>> locking,
>> as this comment states:
>>    // Disable biased locking for this data type. Not only will this
>>    // cause future instances to not be biased, but existing biased
>>    // instances will notice that this implicitly caused their biases
>>    // to be revoked.
>> Or am I wrong?
>
> I read that comment the same way, but I never did get a full grip on  
> the biased locking lifecycle. Perhaps a re-read of the technical  
> descriptions will shed more light - see the linke to the Detlefs &  
> Russell paper in Dave Dice's blog:
>
> http://blogs.sun.com/dave/entry/biased_locking_in_hotspot
>

There's a subtle baked-in assumption in a number of places in hotspot  
that once an object has had biased revoked that it'll remain that way,  
at least over certain intervals.   That constraint could be relaxed,  
of course.

Dave