Re: Thoughts about static linking and reducing size of binaries

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Bryce" == Bryce McKinlay <bryce@albatross.co.nz> writes:

Bryce> I hadn't really thought about this. Are the global constructors
Bryce> really dispersed throughout libgcj.so or does the linker do the
Bryce> right thing and group them together?

They really are dispersed.

The _Jv_RegisterClasses function was introduced so that eventually we
could figure out how to collect all the references together and then
register all the classes for a DLL at once.  We've never implemented
this though.

Someday for fun try running gij under gdb.  Make a breakpoint like
this and run "hello world":

    b _Jv_InitClass
    comm 1
    silent
    printf "%s\n", *klass.name.data @ klass.name.length
    cont
    end

I pretty much choked on the output.  Innocuous calls like:

      if (Modifier::isAbstract(meth->accflags))
        ...

result in calls to _Jv_InitClass.  There are lots and lots of calls.
Sure, these are short-circuited (and maybe could be inlined if we
built with -O2), but for something like Modifier they are also
unnecessary.

One idea I had is that we could change the compiler to recognize that
class initialization is not necessary for certain classes.  For such a
class we could:

* Initialize the state field appropriately
* Create static methods which don't cause class initialization

This optimization might not be appropriate for user code, depending on
the exact semantics we choose (since this choice affects things like
deciding when to rebuild a class), but it would certainly be good for
libgcj itself.

Beyond this we could change important class implementations so that
they don't require class initializations.  Eg if String happened to
require initialization we would change it so that it is initialized by
special startup code in the runtime so that
_Jv_InitClass(String.class$) is never called.


More on the other ideas later.

Tom