Page faults and libgcj.so startup time

[Tom Tromey]

>>>>> "Jeff" == Jeff Sturm <jsturm@one-point.com> writes:

Jeff>                  libgcj    libstdc++    libc
Jeff> R_386_32          27006       1085       146

Jeff> The first of these, R_386_32, is occupied by vtbl entries.

Is this just vtbl entries or does it include other method pointers?

We could reduce this number by changing the `ncode' field in
_Jv_Method to `union { int, void * }' and then initializing it to an
integer vtable offset for virtual functions.

That would mean special cases in a number of places (easily handled by
a method on _Jv_Method) and it would mean that reflection stuff would
be a tiny bit slower.

I don't know whether this is really a win.  It just occurred to me so
I thought I'd mention it.  It feels like a hack, but OTOH if this is a
real performance problem then it might be appropriate.

Another even uglier idea would be to have all the Utf8Consts and other
static data for a class be written as one big chunk of data, and then
use offsets into that structure in various places.  This would reduce
the number of data relocations to one per class.  This would require
changes all over.

Tom