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: values types for Java


On Oct 22, 2003, at 9:17 AM, Adam Megacz wrote:

1. They use interprocedural analysis, which is not compatible with
   separate compilation.

gcj -c Main.java
gcj -c Foo.java

You're doing it wrong.
gcj -c Main.java Foo.java -o bar.o

This distinction is what I was referring to when I wrote "separate compilation".

I guess if you're going to recompile the entire JDK every time you
change one line in your app, then this would work.

Currently, GCJ only does optimizations that affect binary compatibility (right now that means inlining, but this could also include dispatch optimizations and escape analysis assumptions) when it knows the target class is in the same compilation unit. Currently, it only knows this when the class is actually part of the same compilation. I don't think thats a serious limitation for most use-cases, but, if it is we can add a flag which means "assume other classes are in same binary" or alternately "disable binary compatibility with these classes". We could perhaps reuse -fassume-compiled, ie:


-fassume-compiled -> assume all dependencies are in same binary, (for static linking)
-fassume-compiled=foo.*,bar.* -> assume classes in foo and bar packages are in same binary
-fassume-compiled=Foo -> assume class Foo is in same binary


Regards

Bryce.



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