| Dan Gohman | f17a25c | 2007-07-18 16:29:46 +0000 | [diff] [blame^] | 1 | Date: Sat, 19 May 2001 19:09:13 -0500 (CDT) |
| 2 | From: Chris Lattner <sabre@nondot.org> |
| 3 | To: Vikram S. Adve <vadve@cs.uiuc.edu> |
| 4 | Subject: RE: Meeting writeup |
| 5 | |
| 6 | > I read it through and it looks great! |
| 7 | |
| 8 | Thanks! |
| 9 | |
| 10 | > The finally clause in Java may need more thought. The code for this clause |
| 11 | > is like a subroutine because it needs to be entered from many points (end of |
| 12 | > try block and beginning of each catch block), and then needs to *return to |
| 13 | > the place from where the code was entered*. That's why JVM has the |
| 14 | > jsr/jsr_w instruction. |
| 15 | |
| 16 | Hrm... I guess that is an implementation decision. It can either be |
| 17 | modelled as a subroutine (as java bytecodes do), which is really |
| 18 | gross... or it can be modelled as code duplication (emitted once inline, |
| 19 | then once in the exception path). Because this could, at worst, |
| 20 | slightly less than double the amount of code in a function (it is |
| 21 | bounded) I don't think this is a big deal. One of the really nice things |
| 22 | about the LLVM representation is that it still allows for runtime code |
| 23 | generation for exception paths (exceptions paths are not compiled until |
| 24 | needed). Obviously a static compiler couldn't do this though. :) |
| 25 | |
| 26 | In this case, only one copy of the code would be compiled... until the |
| 27 | other one is needed on demand. Also this strategy fits with the "zero |
| 28 | cost" exception model... the standard case is not burdened with extra |
| 29 | branches or "call"s. |
| 30 | |
| 31 | > I suppose you could save the return address in a particular register |
| 32 | > (specific to this finally block), jump to the finally block, and then at the |
| 33 | > end of the finally block, jump back indirectly through this register. It |
| 34 | > will complicate building the CFG but I suppose that can be handled. It is |
| 35 | > also unsafe in terms of checking where control returns (which is I suppose |
| 36 | > why the JVM doesn't use this). |
| 37 | |
| 38 | I think that a code duplication method would be cleaner, and would avoid |
| 39 | the caveats that you mention. Also, it does not slow down the normal case |
| 40 | with an indirect branch... |
| 41 | |
| 42 | Like everything, we can probably defer a final decision until later. :) |
| 43 | |
| 44 | -Chris |
| 45 | |