native methods and static build

Senthil Kumar skumars at
Sun Oct 25 20:26:04 PST 1998

Hi Godmar:

Thanks very much for your information. I will read the JNI
stuff and see what is it that is going/not going wrong.

Godmar Back wrote:

>  The dynamic linking mechanism is disabled in the static configuration.
> It's an either or thing at this point (feel free to fix that! ---
> btw, if you feel like making your jit/intr mix available, that would be
> great too!  I agree with Pat that it's excellent work.)

Yes, that has always been my intention.

I just profiled a Kaffe run on pizza to compile the
.java files in test/awt/WidgetsDemo and it appears as
if more than 60 % of the run time is spent in the GC

This seems rather odd.

Further, it appears as if even a small
change in the way memory is allocated in the code
has a noticable impact on the run time characteristics
of Kaffe. For eg., I would like to verify a method
only once. Unfortunately verify also sets up some
info that is later on used by the code generation stuf.
So, I have to call verify when I intrp the method
and again when I decide to JIT the method. Trying
to save this info generated by verify on the first
run and then releasing it by the JIT run slows down
the code.

I could be very wrong, but I think that the GC implementation
is rather weak, as it stands now.

Also, I was thinking about this findMethodFromPC() method
why can we not stuff in the Method * onto the stack
inside some JIT method, 


pushl %ebp
movl  %esp, %ebp
pushl Method *

popl discard Method *
popl discard MAGIc
popl %ebp

Then getting to some Method * would be trivial?
Perhaps I am missing something??

We can even do away with the MAGIC, can be wrong sometimes,
we can keep a log N search of all Method * and verify
if it is indeed a JIT call.


More information about the kaffe mailing list