This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug java/12772] Need infrastructure to determine if a class in in same binary unit
- From: "tromey at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 14 May 2004 18:05:49 -0000
- Subject: [Bug java/12772] Need infrastructure to determine if a class in in same binary unit
- References: <20031025043704.12772.mckinlay@redhat.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From tromey at gcc dot gnu dot org 2004-05-14 18:05 -------
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12772