Page faults and libgcj.so startup time

Fri Apr 13 00:59:00 GMT 2001

On 13 Apr 2001, Tom Tromey wrote:
> 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?

Vtbl entries are a large part of it. Of course Java often has far more of
these than similar C++ code because instance methods are virtual by
default.
> 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.

Or when the class is init'ed you could swap the vtbl offsets with real
function pointers without changing reflection.
The goal isn't eliminating such costs, but deferring them until a class is
actually needed. It's hard to say how big a win we are talking about
here. My guess is that the benefits will be minimal unless we can reach
the point where entire virtual memory pages of data need not be touched at
program startup.
Startup costs of ~100ms and ~4MB are not bad, and considerably better than
any JDK. But for a certain class of applications that is still
prohibitive.
> 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.

I think it was Jon Olson who first suggested compressed metadata. I
really like that idea both for shrinking the image footprint and
eliminating most load-time fixups. I'd prefer however deferring the
"uncompress" action to class initialization rather than the first use of
reflection.
http://gcc.gnu.org/ml/java/2000-06/msg00086.html
> This would reduce the number of data relocations to one per class.

Or even zero, since a static read-only data structure can be accessed with
PC-relative addressing.
> This would require changes all over.

Maybe not. Since most of the jclass structure isn't needed before class
initialization, why must it be filled in by the compiler? You could leave
it up to _Jv_PrepareCompiledClass to unpack the metadata and fill in the
rest of the jclass record, and most of the runtime wouldn't know the
difference.
As a wild guess, I'd bet we could cut that ~100ms startup down by at least
a factor of 10.
Jeff