[kaffe] [gump] utf8const.c

[Guilhem Lavaux]

Helmer Krämer wrote:
> Davanum Srinivas <dims at yahoo.com> wrote:
> 
> 
>>looks like we need a lock for locking access to utfLockRoot :(
>>
> 
> 
> I'd think that the whole utfLockRoot thing is broken (you'd
> need one utfLockRoot per thread since it's perfectly legal
> for two threads to work on utf8 constants at the same time).
> However, I think we could just remove the utfLockRoot thing
> completely, couldn't we? Even if one of the allocations in
> utf8const.c triggers a garbage collection, the thread holding
> the utf8Lock will be resumed before the finaliser starts to
> free unreachable objects (at least with kaffe-gc). This means
> that we don't have to drop the lock before doing an allocation,
> which renders utf8LockRoot useless. Or I just overlooked
> something ...
> 
> Regards,
> Helmer 

The problem is that utf constants are cached in a hash table. If two 
strings are exactly equals then utf8const does not create a new 
constant. I don't know if the approach is justified but this justifies 
the use UTF locking as only one thread at a time should touch the 
hashtable. The assertion failure in itself is disturbing: it's like the 
fast lock subsystem is not working properly as it lets at least two 
threads running concurrently on that part of the code.

Regards,
Guilhem.