native methods and static build
skumars at earthlink.net
Sun Oct 25 20:26:04 PST 1998
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
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,
movl %esp, %ebp
pushl Method *
popl discard Method *
popl discard MAGIc
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