using gcj for a different language - is it possible?
Tom Tromey
tromey@redhat.com
Fri Jan 9 03:54:00 GMT 2004
>>>>> "Florin" == Florin <fmateoc@mfire.com> writes:
Tom> Offhand I don't remember what sort of inlining we can do. We're sort
Tom> of moving away from doing inlining by default, since that breaks
Tom> binary compatibility.
Florin> You mean for dynamically loaded classes?
Yes, but including classes in shared libraries and classes in the core
library. It turns out that Java applications really do depend on the
binary compatibility semantics (and related things like multiple class
loaders, lazy resolution, etc). It seems to make sense to have this
mode be the default, and then require users to explicitly request gcj
to break Java semantics with a special flag.
Florin> Somewhat related, is there a switch (or has it been
Florin> considered) for informing the compiler that an application is
Florin> not multi-threaded?
You can configure with "no threads", but this code is probably
somewhat bit-rotted. It can't really work properly, anyway, since
Java basically requires finalizers to be run in a separate thread.
(Though semantic trickery may apply to the "no threads"
case... perhaps you don't really hold any locks if all locking
operations are no-ops.)
This is an all-or-nothing configure-time switch. Changing this
doesn't look all that interesting, to me anyway.
Tom
More information about the Java
mailing list