binary sizes

Jeff Sturm jsturm@one-point.com
Thu Feb 19 05:23:00 GMT 2004


On 2004年2月18日, Adam Megacz wrote:
> Anthony Green <green@redhat.com> writes:
> > It should be merging UTF8 literals for ELF targets. Are there other
> > read-only bits that come to mind?
>> Isn't all the reflection data read-only? I guess there's nothing to
> merge there, so it probably doesn't matter... I was just curious why
> it's in .data.

Pointer relocations, perhaps? I don't know if relocs can go into readonly
sections, but even if so, it can't be shared anyway.
The reflection data is unfortunately chock full of pointers. That
makes it slightly bloated, especially on a 64-bit arch.
> BTW, I have the freedom to "break" Java semantics quite a bit for my
> app... for example, we don't need anything post-jdk1.1, and we don't
> use reflection. So if anybody has ideas on ways I can damage gcj in
> order to shrink the binary, that would be really great.

Cool. I'm keenly interested in what you find.
Another interesting side effect of eliminating reflection data: private
methods may become non-addressible, so that they are eliminated by the
call graph if not used, or else have their calling conventions switched to
register passing (on x86). This is a feature of the current cgraph code.
Jeff


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /