Chris Toshok writes:
> I've actually implemented something similar to this (or was in the
> process of implementing it) in my jit written in java, called Aladdin.
> 
> so,
> 
> bipush 14
> istore 1
> 
> would become:
> 
> v1 = 14  <push v1 onto name stack>
> <pop name off stack when you see istore>
> vars[1] = v1

Yes, thats what I meant.

> you don't need to keep track of how many stack slots an item takes up,
> since all that gets compiled away - there is no stack.  pop, dup, all
> those instructions go away.  ElectricalFire works in much the same
> fashion.

Is ElectricalFire still alive?  What is the relationship between ef
and japhar?  

> > I know that good register allocation might cause some overhead when
> > compiling methods (i.e. long startup time).
> 
> Yeah, electrical fire had this very problem with the Character class's
> static initializer.  it was huge, and would take a large amount of
> time to build/color the interference graph.

I know this method, my decompiler also had problems with it (several
10000 instructions just to initialize some big arrays).  The solution
was, to split the code in basic blocks and then do a much simpler
analyzation inside one block (all instructions are sequential, no jump
into this block possible).  I think a similar strategy should be
possible for a register allocation algorithm.

> > But one could include a
> > fast and a slow, but good jit compiler and use the slow compiler only,
> > if the method gets called for the n-th time.
> 
> Yeah, then you run into the interesting problem of what to do if a
> method is in an infinite loop, calling other methods. you'd never
> compile the method with the loop in it.  The interesting problem is
> how to reliably replace the running interpreted code with jitted
> code - or more generally how to replace running code with more highly
> optimized code.

Well, I wouldn't optimize this method.  I think the more common
bottlenecks are methods, that get called very often from a loop.
Methods with long runtime tend to be simple.  They just call other
methods, that do the real work.  At least that is what I hope.

  Jochen

Reply via email to