This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cross-module inlining (was Re: using gcj for a different language- is it possible?)


Jeff Sturm writes:
 > On Mon, 9 Feb 2004, Andrew Haley wrote:
 > >  > I've been thinking a little about this since it can restrict inlining,
 > >  > escape analysis, and any other sort of useful IPA gcj might perform.
 > >
 > > If you want to do IPA, compile the files at the same time, and this
 > > gives gcj carte blanche to do any optimizations it can find, including
 > > full inlining.  Separate compilation, however, implies binary
 > > compatibility.
 > 
 > Yes.  Well, almost.  I don't think gcj should have carte blanche
 > when building a library, unless it continues to disallow class
 > replacement at runtime.

Well, compiling everything together rather implies that, because calls
can be made directly between classes.  Anyone who really wants to
replace an individual class in a library at runtime had better not
compile a whole library with -O3.  But that's up to them.

 > >  > Similarly in Java, why not leave the most aggressive optimizations
 > >  > for the main executable (non-PIC) and stick to conservative
 > >  > binary-compatible optimizations for libraries?  Does binary
 > >  > compatibility really matter for non-library code?
 > >
 > > That's up to the user, surely.  I don't think we need to have any
 > > particular policy here.
 > 
 > Going back to the OP:
 > 
 > "We're sort of moving away from doing inlining by default, since that
 > breaks binary compatibility."

That was what I was disagreeing with.  We have never inlined by
default, only with -O3, and only in a single compilation.

 > Sounds like the preferred policy will be indirect dispatch (binary
 > compatibility) everywhere.

The default policy, yes.  By default we comply with the JLS.

 > My simple suggestion is that indirect dispatch is really only
 > needed for libraries, and by default more aggressive IPA can be
 > done for classes compiled into the main executable.

No, that's wrong.  You build an executable from a number of objects.
You don't want to have to recompile all its callers whan a class
changes.  This is true whether the class is in a library or not.

Surely our default should be compliance with the JLS.

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]