heap fragmentation?

[Jeff Sturm]

On Fri, 7 Jun 2002, Bryce McKinlay wrote:
> Part of my grand binary compatibility plan is to not have static class 
> data. Instead, class metadata would be entirely symbolic (no pointers 
> except to local utf8consts), and java.lang.Class objects would be 
> created at runtime as classes are initialized. This would reduce binary 
> size and linker startup time. Static class fields would be "inlined" 
> into the class object. In this case there would be no static data at all 
> for the GC to scan (presuming we place restrictions on static references 
> in CNI), everything would be reachable from the stack.

Great plan.  I'd like to work towards that too.  If all static members can
be addressed at constant offsets from the class pointer, that takes care
of the class initialization test we do now.  Anyway, modern CPUs can
perform offset addressing very efficiently, whereas the instructions to
load a fixed address can be downright ugly (it can be up to 7 insns on
alpha).

Not to mention the savings in relocations, etc. that might also help with
the link overhead at build time that others have complained about.

Incidentally, I've begun building all our code with --indirect-dispatch.
The libraries are far too brittle without it.  For one thing, we still use
javac in our build (gcj -C isn't quite ready for executable bytecode)
which has a funny habit of sorting the methods.  Distributing a
javac-compiled jar with a DSO built without --indirect-dispatch is doomed
to fail.

> A potential disadvantage (or an advantage depending on which way you 
> look at it) of this approach is that it pushes link errors like missing 
> classes to runtime.

So we get a more Java-like linkage model... what's the problem?

Another benefit is that this would help support non-ELF shared library
targets, e.g. win32, AIX, ... .  Right now libgcj is too dependent on ELF
semantics.

Jeff