statically linked executable size
Wed Jul 5 22:28:00 GMT 2006
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)
* 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 :-)
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)
* 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
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.
More information about the Java