about non-compatible optimization (was: Re: patch to bring java vtables closer to g++ abi conformance)

Adam Megacz gcj@lists.megacz.com
Mon Jan 28 11:08:00 GMT 2002

> > Closed world optimizations would certainly be nice in some cases.
> > However they also:
> > - Prevent Java's dynamically extenisbility
> > - Prohibit dynamic linking (at least if you want to keep binary
> >   compatibility)

Yes, I see static linking as useful mainly for two specialized
situations: embedded work (where library upgrades carry no advantage)
and mobile code (applets, activex, xwt) where you can't afford to
distribute libgcj.so to people who don't have it.

> > - Would require a lot of new compiler infrastructure in order to
> >   do them well

Could you elaborate a bit on this? I'm getting kinda hooked on static
compilation for the peculiar kind of work I do, so I have an interest
in seeing support for it continue. I'm pretty content with method-gc
as a post-compile optimization, though.

> is libgcj so stable that you can just depend on it and not worry
> about the next week?

Perhaps not, but the Java standard library API is pretty stable. With
Bryce's indirect patch, you can just assume that libgcj correctly
implements the Java2 API. If there is a bug, libgcj.so can be upgraded
and your program will automatically take advantage of the bugfix.

Very slick indeed.

  - a

More information about the Java mailing list