|Summary:||Need infrastructure to determine if a class in in same binary unit|
|Product:||gcc||Reporter:||Bryce McKinlay <bryce>|
|Component:||java||Assignee:||Not yet assigned to anyone <unassigned>|
|Severity:||normal||CC:||gcc-bugs, java-prs, pinskia|
|Build:||Known to work:|
|Known to fail:||Last reconfirmed:||2006-03-05 03:50:32|
|Bug Depends on:|
Description Bryce McKinlay 2003-10-25 04:37:05 UTC
In order to make the right decision about whether to optimize field access and certain method, a function needs to be added to GCJ to determine if a class is in the same translation unit. It should also be possible for the user to specify that dispatch to certain classes or packages should be treated as non-binary-compatible, with a flag such as -fassume-local.
Comment 1 Andrew Haley 2004-05-14 16:26:01 UTC
Suppose that the classpath is foo.so:bar.so and suppose that a class is found in bar.so. We should first try to resolve that class's dependencies in foo.so, even though it may be possible to resolve them in bar.so. So, even if we could determine that a class was in the same binary unit, it wouldn't be binary compatible to optimize based on that, at least not by default. -fassume-local does provide a way around this: the user is asking the compile to ignore binary compatibility rules.
Comment 2 Tom Tromey 2004-05-14 18:05:46 UTC
I think comment 1 was referring to optimizing accesses to private outer fields. For object code we could do this by adding a special permission bit (or equivalent) that is used when code comes from the same translation unit. There are a few pathological cases here, where in theory you can do runtime class replacement, but in practice it won't really work. E.g., a local or anonymous class can capture final local variables, but there is no standard for how these variables end up in the class -- every compiler is free to implement it differently. Replacing one of these inner classes at runtime is strange and probably would not work well in practice. Accessing private outer fields falls into this category as well. There is no standard controlling the names of the accessor methods that are added to the outer class. Given that, it is hard to see how the language standard can claim that binary compatibility actually makes sense here. But, if we really want to go this route, then I think we will have to always generate the accessor methods, regardless of whether we're generating .class or .o. E.g., the user could conceivably replace an inner ".o" with an inner ".class" representation -- but this representation wouldn't have access to whatever special hack we put in the runtime.
Comment 3 Bryce McKinlay 2004-05-14 18:20:00 UTC
When "intra translation unit" optimizations are enabled, which will be the case unless runtime class replacement is needed, then there is no need for a special accessibility flag because the compiler can use direct field access within the binary - see my comments on bug 15363. If we want "extra binary compatibilty", ie the ability to replace individual classes within a compilation unit at runtime, then its probably best to just use the accessor methods here.
Comment 4 Andrew Pinski 2016-09-30 22:53:32 UTC
Closing as won't fix as the Java front-end has been removed from the trunk.