Home | History | Annotate | Download | only in HistoricalNotes
      1 Date: Sat, 19 May 2001 19:09:13 -0500 (CDT)
      2 From: Chris Lattner <sabre (a] nondot.org>
      3 To: Vikram S. Adve <vadve (a] 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 
     46