This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: statically linked executable size
Tom Tromey writes:
> Ranjit> What seems to happen is that we have java.lang.SecurityManager
> Ranjit> that directly uses java.awt.AWTPermission.
>
> Yeah, this is an odd special case in there.
>
> Andrew> Now comes the question: how shall we fix this? We can either
> [...]
> Andrew> * or we can compile AWTPermission separately from the rest of AWT
>
> I lean toward this.
>
> We've talked about splitting libgcj.so into a few libraries before.
> I think we ought to do it. I was thinking of having 4 pieces, at
> least to start with:
>
> * AWT + Swing (and BC compiled)
> * CORBA
> * XML provider bits
> * The rest
>
> To make this work we have to special-case AWTPermission... there's
> already a comment in makemake.tcl about this class :-)
Sounds good.
> The plus side to doing this is that we can have better startup and
> lower overhead for programs which only rely on the core -- and this is
> a fair number of programs.
>
> The drawbacks that I know of are:
>
> * Performance hit for AWT/Swing code (though we don't know if it is
> important or large enough to be noticed)
What performance hit?
> * CNI messiness with BC code
> * Users would have to know to link in these libraries if they wanted
> to use them from CNI-style compiled program (or statically linked
> program)
>
> Andrew> I've appended the fix for SecurityManager, but that doesn't help at
> Andrew> all because java.text.Bidi uses java.awt.font.NumericShaper. However,
> Andrew> nothing actually _refers_ to java.text.Bidi.
>
> I didn't know about this one... we could BC-compile Bidi.
No; the whole idea of this is surely to fix static linkage, but
BC-compiling classes will have exactly the opposite effect becasue
their dependencies won't be linked! :-)
The _right_ answer to all this for people who need static linkage is
to be able to compile separate .o files for static libraries.
Painful, I know, but there it is,
Andrew.