native methods and static build

[Godmar Back]

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

 "Sad" is a better word than "odd" to describe this state of
affairs.  I checked in a patch to fix one of the most glaring inefficiencies 
in kaffe's gc a while ago (the precise gc patch, see the ChangeLog).
You should apply that patch/update to a later version and see again
how much time is spent in the gc.  Some work is underway to fix some
of the other inefficiencies.  Hopefully, we get the gc at least up
to the standard of tracing stop-and-go collectors (which is the state
of the art 8 years ago) --- I know of a few people who are working
on more modern gc algs; lets hope something is going to come out of
this.

Also, don't forget about the -mx and -ms switches -- they at least
reduce the frequence of calls to the gc.

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

 That seems entirely possible.  Remember that Kaffe wasn't designed
to both jit and intrp.  Also, in some parts, the implementation of components
has been consciously kept single-threaded, because using static variables
is more efficient that allocating and freeing memory.

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

 Safe to say that you're not "very wrong".

	- Godmar