This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: What's the state of efforts to reduce GCJ's footprint?
- From: Tom Tromey <tromey at redhat dot com>
- To: Jim Mayer <jim at pentastich dot org>
- Cc: GCJ <java at gcc dot gnu dot org>
- Date: 31 Jan 2007 18:07:07 -0700
- Subject: Re: What's the state of efforts to reduce GCJ's footprint?
- References: <17856.32643.234003.34938@zebedee.pink> <1170295493.11260.64.camel@perdita.danbury.local>
- Reply-to: tromey at redhat dot com
>>>>> "Jim" == Jim Mayer <jim@pentastich.org> writes:
Jim> a few years ago people were complaining about the size of
Jim> minimal gcj compiled applications that seem downright tiny now.
That's progress!
:)
Jim> Since there's so much stuff out there I'm hoping that someone will point
Jim> me to some good information on the topic. I can see that a lot of
Jim> internal compiler work has been going on (the new ABI stuff, major gcc
Jim> changes, a new byte code compiler, etc.) and I'm having trouble figuring
Jim> out how much of the stuff Google turns up is still relevant.
Off the top of my head:
* Many people doing static linking make a custom libcj, removing
things they don't like.
* -freduced-reflection might help somewhat, but of course it affects
what kinds of programs you can run. I'm not sure whether you can
build all of libgcj this way or not; David Daney would know. Or
perhaps Google.
* There's micro-libgcj at one extreme of the spectrum.
There's still no really general solution that I'm aware of.
Tom