1*9880d681SAndroid Build Coastguard WorkerDate: Sat, 19 May 2001 19:09:13 -0500 (CDT) 2*9880d681SAndroid Build Coastguard WorkerFrom: Chris Lattner <[email protected]> 3*9880d681SAndroid Build Coastguard WorkerTo: Vikram S. Adve <[email protected]> 4*9880d681SAndroid Build Coastguard WorkerSubject: RE: Meeting writeup 5*9880d681SAndroid Build Coastguard Worker 6*9880d681SAndroid Build Coastguard Worker> I read it through and it looks great! 7*9880d681SAndroid Build Coastguard Worker 8*9880d681SAndroid Build Coastguard WorkerThanks! 9*9880d681SAndroid Build Coastguard Worker 10*9880d681SAndroid Build Coastguard Worker> The finally clause in Java may need more thought. The code for this clause 11*9880d681SAndroid Build Coastguard Worker> is like a subroutine because it needs to be entered from many points (end of 12*9880d681SAndroid Build Coastguard Worker> try block and beginning of each catch block), and then needs to *return to 13*9880d681SAndroid Build Coastguard Worker> the place from where the code was entered*. That's why JVM has the 14*9880d681SAndroid Build Coastguard Worker> jsr/jsr_w instruction. 15*9880d681SAndroid Build Coastguard Worker 16*9880d681SAndroid Build Coastguard WorkerHrm... I guess that is an implementation decision. It can either be 17*9880d681SAndroid Build Coastguard Workermodelled as a subroutine (as java bytecodes do), which is really 18*9880d681SAndroid Build Coastguard Workergross... or it can be modelled as code duplication (emitted once inline, 19*9880d681SAndroid Build Coastguard Workerthen once in the exception path). Because this could, at worst, 20*9880d681SAndroid Build Coastguard Workerslightly less than double the amount of code in a function (it is 21*9880d681SAndroid Build Coastguard Workerbounded) I don't think this is a big deal. One of the really nice things 22*9880d681SAndroid Build Coastguard Workerabout the LLVM representation is that it still allows for runtime code 23*9880d681SAndroid Build Coastguard Workergeneration for exception paths (exceptions paths are not compiled until 24*9880d681SAndroid Build Coastguard Workerneeded). Obviously a static compiler couldn't do this though. :) 25*9880d681SAndroid Build Coastguard Worker 26*9880d681SAndroid Build Coastguard WorkerIn this case, only one copy of the code would be compiled... until the 27*9880d681SAndroid Build Coastguard Workerother one is needed on demand. Also this strategy fits with the "zero 28*9880d681SAndroid Build Coastguard Workercost" exception model... the standard case is not burdened with extra 29*9880d681SAndroid Build Coastguard Workerbranches or "call"s. 30*9880d681SAndroid Build Coastguard Worker 31*9880d681SAndroid Build Coastguard Worker> I suppose you could save the return address in a particular register 32*9880d681SAndroid Build Coastguard Worker> (specific to this finally block), jump to the finally block, and then at the 33*9880d681SAndroid Build Coastguard Worker> end of the finally block, jump back indirectly through this register. It 34*9880d681SAndroid Build Coastguard Worker> will complicate building the CFG but I suppose that can be handled. It is 35*9880d681SAndroid Build Coastguard Worker> also unsafe in terms of checking where control returns (which is I suppose 36*9880d681SAndroid Build Coastguard Worker> why the JVM doesn't use this). 37*9880d681SAndroid Build Coastguard Worker 38*9880d681SAndroid Build Coastguard WorkerI think that a code duplication method would be cleaner, and would avoid 39*9880d681SAndroid Build Coastguard Workerthe caveats that you mention. Also, it does not slow down the normal case 40*9880d681SAndroid Build Coastguard Workerwith an indirect branch... 41*9880d681SAndroid Build Coastguard Worker 42*9880d681SAndroid Build Coastguard WorkerLike everything, we can probably defer a final decision until later. :) 43*9880d681SAndroid Build Coastguard Worker 44*9880d681SAndroid Build Coastguard Worker-Chris 45*9880d681SAndroid Build Coastguard Worker 46