Rewriting byte codes

Erik Corry erik at
Sun Mar 31 11:02:46 PST 2002


I'd like to make some changes to Kaffe to make it simpler to
do more precise GC.  What would be needed at a minimum would

* Split local variables that can be either reference or non-reference
  into two.  (The alternative is to keep track of when they are what).
* Keep track of which stack positions are references when we do a
  call or new.  Luckily the stack is zapped on an exception so we
  don't have trouble there.
* Make copies of jsr code so that each basic block can only be called
  from one jsr call point chain (default the null chain of course)

There's an obvious problem that when we split the variable, one
of the new variables could end up above the 256 byte level.  Similarly
we could end up with more than 65536 bytes in a method.
In order to fix this a little byte code rewriting is inevitable.  I
would suggest we rewrite the byte codes such that:

* All insns are wide (16 bit index to local variables), and we drop
  the wide prefix
* All inline constants are native-endian
* All pc indexes are 32 bits and of course native endian (mostly a
  problem with the exception table I think, also replace GOTO with
  GOTO_W throughout)

Copying jsr code is very nice because it means all problems related
to jsrs just disappear.  We can replace jsrs and rets with gotos.
You are not allowed to recurse with jsr (though you are allowed
nesting) so semantics should be preserved.

In theory it can give exponential code expansion, in practice I
doubt it does.  I don't think you can construct an example in
Java that gives exponential code expansion, and if you had byte
code that did that, it would take exponential time to verify, so
it's a bad idea anyway.

Any comments?  I'm not guaranteeing I'll have time, but right
now it looks as though I may need it for something else anyway.

Erik Corry

More information about the kaffe mailing list