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