Rewriting byte codes
Erik Corry
erik at arbat.com
Sun Mar 31 11:02:46 PST 2002
Hi
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
be:
* 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