A bug with automatic variables and finally

[Tim Wilkinson]

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
pointlessly difficult.

> 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
exceptions?
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.

Cheers
Tim

--
  Tim Wilkinson                         Tel/Fax: +44 181 440 0658
  T. J. Wilkinson & Associates,         Mobile:  +44 370 621006
  London, UK.                           Email:   tim at tjwassoc.co.uk