hotjava

[Parmelan, Edouard]

Hi Godmar,

> The likely reason for that is that an exception occurred during
> class processing, the main thread left processClass, but processClass
> is buggy in that it doesn't release the classLock, and voila.
> 
> We know about that bug.
> So, for now: either try to fix that bug (the solution is to use error
> codes insteads of throwException) or, as a work-around, find out why
> that exception is thrown and do something about it to prevent that from
> happening.
I try an other solution: Manage StaticLock Regions.
In such region, if an execption is throw, try to unlock the static lock.

The region should be a function in witch the static lock is get at
beginning and release at end.
As thowing an execption in that region release the lock, don't release it
manually before call throwException().


The following patch is a proof of concept.
[two functions addStaticLockRegion() and findStaticLockInRegion() should
be in lock.c]

This work for JIT only.  I don't know how to do it for the intrp engine
without changing all the code.

I add two regions:
  processClass()
  translate()

Edouard.

PS: HotJava could definitly don't work with Kaffe as it use the class
sun/misc/VM which nead some native functions...

---
 <<kaffe-ccatch.patch>> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kaffe-ccatch.patch
Type: application/octet-stream
Size: 3436 bytes
Desc: not available
Url : http://kaffe.org/pipermail/kaffe/attachments/19981116/f27fbfeb/attachment-0006.obj