Re: GC statistics (was Re: big project ported)

[Godmar Back <gback at cs dot utah dot edu>]

> 
> 
> Jeff wrote:
> > Yes.  That's what I'm finding out too.  My code is greatly affected by
> > the frequency of allocation, not the overall size.
> 
> Can you build a statically linked version of your app?  One bad thing
> right now is that there are a lot of calls between libgcj.so and
> libgcjgc.so during gc.  Calls across shared library boundaries are
> slow.
> 
> Eventually we will have to move the java specific marking into the
> gc's inner-loop, but I'm curious about the real cost of the shared
> library calls.
> 

The loop in _Jv_MarkObj does look expensive.

Related to that, latte uses it JIT to emit class-specific walk functions
for each class at translation time.  It seems gcj could do the same.
There would be some overhead in code space, yes.  But the walk
functions of classes with identical layout could be shared.


The other option, which is slower, but presumably still a lot faster 
than the current state of affairs is to do what I did for kaffe: create 
a bitmap for each class (ideally in the same format so I don't have
to recompute it for gcj classes:-)  The code is in 
kaffe/kaffevm/classMethod.c:resolveObjectFields; it should translate
nicely to libgcj.

The bitmap in kaffe contains sizeof(ThisObject)/ALIGNMENT_OF_VOIDP
bits.  So say if the object is

struct {
	void	*dtable;
	void	*lockfield;
	int	x;
	short	y;
	Object	*obj;
}

the bitmap would be "00001" on an architecture that aligns void*s
at four, and it would be "000000010" on an architecture that aligns
void*s at two (m68k).

	- Godmar