From: Archie Cobbs (archie@whistle.com)
Date: Wed Sep 09 1998 - 15:01:58 EDT
Godmar Back writes:
> I should mention that Tim and I discussed another very similar problem
> before. The other problem concern the fact that if an exception is
> thrown while the VM takes a lock, this lock is not unlocked, hence
> preventing other threads from forever entering that piece of code
> (example: processClass and the static lock it takes)
>
> Tim at this point argued that it might be sufficient to keep track
> of the locks a threads holds, and unlock those if an exception is
> thrown, essentially cleaning up after that thread.
>
> However, in the case of verifyMethod/verifyBasicBlock, it appears
> that simply releasing a lock might not be sufficient: tidyVerifyMethod
> must be called as well. Of course, it might be possible to implement
> a scheme where threads register "clean-up handlers" before entering
> a block of code in which they could throw an exception. These
> clean-up handlers could then unlock locks or perform other cleanup,
> such as tidyVerifyMethod. In essence, this would amount to try/catch
> blocks in C.
>
> Another alternative, which would work with Tim's idea of keeping track
> of locks and unlocking them if necessary, is to require all code to be
> able to deal with exceptions. That would mean that all code would have
> to be reentrant. Currently, this is not the case.
>
> What do you think?
Here's a wacky idea (this is only 1/2 kidding... :-)
1. Rewrite kaffe in Java, leaving as little as possible in C (eg,
thread context switching, acquiring locks, performance critical
code, etc.).
2. Use GCJ -O3 to compile the Java into optimized binary code.
Then all of the above problems become easy because you can rewrite
processClass() in Java. The bootstrap problem of class loading
goes away because the GCJ compiler "loads" all of the basic classes
for you at compile time.
Ok, so maybe it would never happen, but it makes for a real
good thought experiment...
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:56 EDT