hotjava

[Godmar Back]

 Edouard,

 Unfortunately, releasing static locks is only part of a more fundamental
problem.   In other instances, the problem results in memory leaks and 
state corruption.  Basically, if a function doesn't return because it
throws an exception, the caller won't have a chance to clean up its local
state (locks, memory, other data structures).
Look at such functions as tidyVerifyMethod or functions that need to free
memory before returning.

We discussed various solutions, and decided to go with old-fashioned
error code propagation.  I have a simple error code based solution almost 
done, and hope I'll be able to check it in soon.
With that code, I did in fact get to the sun.misc.VM problem already.

	- Godmar

> 
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------ =_NextPart_000_01BE1188.001A7D99
> Content-Type: text/plain
> 
> 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...
>