Re: exceptions & dataflow

"Sergey Solyanik" <sergey@solyanik.com> writes:
> In Java, hardware exceptions can ony happen in very controlled manner
> (e. g. to test for null). If your language contains pointers, things
> are much worse and you'd have to break basic block with essentially
> any pointer dereference when you cannot prove that location exists.


In Java the biggest complication exceptions create for optimisation is
asynchronous exceptions. Java defines a mechanism by which one thread
can send an exception up another thread's stack at any time.


A simple implementation would treat this something like a Unix signal,
which can interrupt the execution of any bytecode. Since the VM spec
disallows reordering of bytecodes with globally visible side-effects
(changing memory, for example), this can pretty much inhibit all
non-trivial optimisation.


A more subtle approach is to have sample points in generated JIT
code which checks for pending exceptions, and only process them when
convenient. This has to be done pretty regularly though, probably in
every basic block, which adds its own overhead.


Asynchronous exceptions were a terrible mistake for other reasons (they
introduce race-conditions in the try/catch/finally mechanism and all
code must expect any exception at any moment), they're being deprecated.
We're stuck with them for now, though.


J
--

Return to the comp.compilers page.
Search the comp.compilers archives again.