A bug with automatic variables and finally
tim at tjwassoc.co.uk
Thu May 1 12:45:07 PDT 1997
Richard Henderson wrote:
> > The simplest thing to do is to make sure registers are always
> > written back to memory before executing instructions which may cause
> > runtime exceptions.
> As was pointed out on another thread, exceptions can also be
> asynchronous, so this does not bear up.
You mean asynchronous like one thread can generate an exception in
another? Given this is the case how the hell do they write an
efficient interpreter where each Java instruction is guaranteed
to be atomic (I think they say they are somewhere)? I sometimes think
these people get up real early and try real hard to make this
> There is another approach that might be taken. You should be able
> to, for each jvm insn in the try-block, record in which registers
> the local variables reside. You can then either use that information
> from C in the exception restart code, or in assembly by creating
> custom exception handler entry points that move registers in place
> for the standard exception handler.
Don't get me wrong, this sounds fesible enough ... but it also sounds
messy and ever so slightly big. For the moment I could see how it might
be done - but when the JIT gets a bit more optimised this is going to be
(a) a nightmare, and (b) restrictive on what optimisation can be done
(e.g. I can see sitution where I'd want to store a result straight back
into the register shadowing a local but couldn't because it'd invalidate
the causal order of the program if we got an asychronous exception).
> One tricky point is that, during the try block, you'd want to
> update locals in registers atomicly. I don't think this is a big
> deal for most of the things you want to do to locals -- add for
> instance -- but something to keep in mind.
Oh I just see a vast hole opening in front of me with a little sign over
it saying "optimisation pitfall - this way"
> Again things are more efficient if the recording of locals is
> limited to those actually used by the exception handler.
> All of this is somewhat non-trivial, but it does seem like a correct
> solution in that it produces the "expected" results as well as
> imposing little or no run time penalty when no exception occurs.
But what I want to know is, what do Javasoft claim for runtime
Do they really expect this kind of behaviour, and if they do can someone
point me at the text so I can read it then go and have a bit of a cry.
Tim Wilkinson Tel/Fax: +44 181 440 0658
T. J. Wilkinson & Associates, Mobile: +44 370 621006
London, UK. Email: tim at tjwassoc.co.uk
More information about the kaffe