Interesting paper on Supporting Binary Compatibility with Static Compilation

[Jeff Sturm]

On Mon, 12 Aug 2002, Andrew Haley wrote:
> 2% of _total_ runtime?  That seems like an awful lot.  Still, if it's
> needed to achieve binary compatibility I suppose we'll have to live
> with it.  However, given my current interest in improving run-time
> performance I don't like to see regressions.

Those who want maximum performance will always build with -static, I'm
afraid.  For static linking binary compatibility is mostly a non-issue.

Currently the shared/static builds are identical except for -fPIC.
Couldn't you toggle on/off binary compatibility options similarly?  I
don't know how you'd coax libtool to do it, though.

> Also, one of the great advantages of ahead-of-time compilation is fast
> startup; we don't want to lose too much of that either.

It should improve, actually.  Same for memory footprint.  Right
now gcj does quite poorly on both, especially for DSOs.

For example: -findirect-dispatch defers vtable construction, eliminating a
good number of symbolic relocations per class.  But unfortunately the
offset table adds even more absolute relocations.  So the improvement is
marginal, if any.

That isn't hard to fix for indirect dispatch, because the vtable is part
of the ABI, whereas the offset table isn't.  Just choose another otable
layout that doesn't require linking pointers.

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.

Jeff