values types for Java

Bryce McKinlay bryce@mckinlay.net.nz
Tue Oct 21 21:58:00 GMT 2003


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.


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /