Interesting paper on Supporting Binary Compatibility with Static Compilation

[Jeff Sturm]

On Mon, 19 Aug 2002, Bryce McKinlay wrote:
> When thinking about the layout of the class and binary compatiblity
> structures I've worked on the assumption that non-symbolic, private
> relocations within the same binary object are much cheaper than symbolic
> relocations (like the vtable ones) which need to be looked up globally.

Right.  Any relocation still costs, though.  I realize that without
prelinking, the pointers have to be fixed up sometime, somewhere in any
case.  I'm interested in deferring that fixup until class init.

> However on Linux, libgcj's startup time is still insignificant compared
> to the Hotspot VM, especially with the most recent glibc versions.

For small executables, I agree.  But Hotspot's startup time is pretty much
constant, whereas gcj-compiled executables have a startup overhead that
increases with each shared library linked in.

It's not just a gcj problem.  The KDE folks have been dealing with this
for a while.

> Other
> OSs like Mac OS X support prelinking which basically eliminates the need
> for runtime relocations (at the cost of waiting around while prebindings
> get updated every time you install an updated), so it isn't really an
> issue there either.

Windows does something similar.  Someone (Jakub?) was working on
prelinking for GNU; I don't know whether he finished.

> While it would possibly allow us to make the metadata completely static
> (not just the strings), saving some startup time, I'm not convinced,
> given the fairly small size of the structure above, that it would be
> worthwhile due to:
>
> a) extra metadata size (in the binary) due to loss of merged utf8consts

Hmm... I didn't know we can merge these now, I'll have to look at that.

Per suggested replacing pointers with 16-bit offsets, that would save some
space, especially on 64-bit targets.

> b) extra code complexity in compiler and libgcj to deal with the
> metadata format not being arranged in nice simple pointers

What about something resembling the class file format, minus code
attributes?  It's fairly compact and libgcj already knows how to read it.

I'm not convinced one way or the other, truthfully.  Unfortunately I
don't find experiments all that easy when the frontend is involved.  Any
improvement is welcome, though...

> With this scheme, and with class fields being part of the class objects,
> static data wouldn't need to be scanned at all. Class objects would be
> on the heap so everything would be reachable from the stacks.

Sounds good to me.  I experimented with this once and found the actual
size of static roots in libgcj (apart from classes) is tiny:

http://gcc.gnu.org/ml/java-patches/2002-q2/msg00490.html

My main concern is the possible existence of any CNI code that currently
relies on scanning static areas.

Jeff