Re: Interesting paper on Supporting Binary Compatibility with StaticCompilation

[Jeff Sturm <jsturm at one-point dot com>]

On Mon, 12 Aug 2002, Andrew Haley wrote:
>  > As a data point, when I build my CMS app with gcj I have 7 DSOs totalling
>  > about 190,000 load-time relocations (not counting libgcj.so).  Some of
>  > these are resolved lazily, most are in .data and cannot be.  Startup
>  > time is about 2 seconds on sparc-solaris and initial memory footprint
>  > around 28MB.  Not too impressive, compared with 1 second and 15MB for the
>  > JRE.
>
> That's weird, because IME interpreted Java takes forever to start
> because of lazy class loading.

Yes, but... there are some 1900 classes in my app, plus another 1326 in
libgcj.jar.

With the JRE, I see just 296 classes loaded initially, and 395 when it
reaches steady-state.

With gcj, I have to wait for ld.so to link ~3200 classes before anything
happens.

I understand I could try pruning classes I don't need from the DSO, but
that's not all that easy to do, and many classes/interfaces are there
only to resolve link-time references... they may never get initialized at
run time.

Or I could try -static.  But I don't want a monolithic executable either.
I'd prefer to distribute .jar files or shared libraries.

Suppose the compiled class metadata were free of pointers instead.  No
relocations, except lazy function calls.  The metadata could then be
constant and loaded into .rodata.  Some advantages:

a) It would be shareable with other processes, whereas the current
metadata is loaded into a COW segment.

Relocation processing destroys page sharing since it touches the affected
pages at startup.

Observing page faults at startup, I get 473 faults with the JRE vs.
1821 with the gcj-compiled app.

b) Page allocation may be deferred until the class is initialized.

If class metadata is neither read nor written at startup, it will have
zero impact on process footprint.

c) GC would have a far smaller root set.

This is a major contributor to collection times.  The GC must scan ~6MB of
static data per collection, almost none of which contains any heap
pointers.

Jeff