[kaffe] Lock patch

[Guilhem Lavaux]

Guilhem Lavaux wrote:
> Helmer Krämer wrote:
> 
>> Guilhem Lavaux <guilhem at kaffe.org> wrote:
>>
>> Hi,
>>
>>
>>> I've just finished a functional patch for the locking system. I don't 
>>> know yet how much slower it is. But I've already had some interesting 
>>> results with some private app which was not working previously. If 
>>> noone is against  I will commit it on wednesday...
>>
>>
>>
>>
>> If nobody owns the lock, the jthread_t of the current thread is stored in
>> *lkp (afterwards called thin lock). If the same thread tries to lock the
>> mutex again, or another thread tries to do so, a heavy lock will be 
>> allocated.
>>
>> If *lkp does not point to a heavy lock, a new one is allocated on the 
>> heap.
>> To preserve the state of the lock when a thin lock is replaced by a heavy
>> lock, new->holder is initialized with the current value of lk, and 
>> lockCount
>> is set if necessary. Afterwards an attempt is made to install the 
>> heavy lock.
>> If that doesn't work (either because the lock was freed or because 
>> another
>> thread already installed a heavy lock), the heavy lock is freed and we 
>> start
>> again with checking whether *lkp is a heavy lock. Once we got a heavy 
>> lock,
>> we wait for the heavy lock to become usable by the current thread, 
>> just like
>> your code does.
>> What do you think of this?
>>
> 

I've forgotten another thing. I'm wrong not to call gc_free in 
putHeavyLock as we are leaking memory at that place (for objects I 
mean). If we want to cache the heavy lock we should either follow Tim's 
advice or transform the fixed memory allocation by a garbage collected 
memory.

Guilhem.