Trampolines in the Kaffe JIT Compiler

[Godmar Back]

> 
> 
> 
> Thanks for the feedback.  I have added the last-update date and version
> number of Kaffe to the document.  This document was released today and
> was intended to describe Kaffe release 1.0.5.  I would like to make this
> paper up-to-date, but I have not seen the anchor mentioned.  Could you
> give me a code location (and example architecture if this part of the
> trampoline is architecture-dependent) for where to get started?
> 
> Also, I believe the case studies in the document are accurate at least to
> the last release 1.0.5 of SPARC and i386.  Does this mean that the code for
> SPARC and i386 is broken, or am I misunderstanding something?  If still
> broken, how severe is this?  Would it be worth fixing on SPARC and/or
> i386?  Thanks again.
> 

What's broken is 1.0b5.
For the changes, see for instance:

cvs diff -r1.70 -r1.73 classMethod.c

They're labeled in the changelog as gcj related changes, but it's
also a big bug fix/cleanup for trampolines.

The main problem was that the old trampoline could have only one
anchor.  That is, once you jump thru it, there was only one position
you could patch/update.  As a result, if you had inherited methods
to which two dtable entry referred, only one would get patched.
The other would go through the trampoline every time.

The solution is to create a trampoline for each location in which
we store a pointer to the method in question.  This also works nicely
for the interface dispatch tables, btw.

Anchor, btw, is my own lingo for the third, the "where" parameter in
FILL_TRAMPOLINE.

I think if you just look at the code, you'll see immediately what I mean.

	- Godmar