native methods and static build

[Senthil Kumar]

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
code. 

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, 

eg.

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

...
...
popl discard Method *
popl discard MAGIc
popl %ebp
ret

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.

Senthil