Bug 15363 - Binary Compatibility: need special access control
Summary: Binary Compatibility: need special access control
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: libgcj (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Blocks: 12725
  Show dependency treegraph
Reported: 2004-05-10 05:04 UTC by Tom Tromey
Modified: 2005-07-23 22:39 UTC (History)
3 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2005-06-20 04:14:20


Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tromey 2004-05-10 05:04:03 UTC
For the BC ABI, we will either need to generate access$0 methods
like we do when generating .class files, or we will need to
have a special case in the access control checking for this 
situation (these methods are made when an inner class accesses
a private method of a containing class).

I'd prefer we make a special case.  All situations requiring
this occur for code in a single compilation unit, something
we can probably check easily at runtime.
(Note that we probably cannot assume that inner classes from
a given compilation will necessarily be those returned;
a malicious class loader might do something different.)
Comment 1 Andrew Pinski 2004-05-10 15:23:28 UTC
Comment 2 Bryce McKinlay 2004-05-10 15:57:20 UTC
Note that when field access occurs within a compilation unit, we can optimize
dispatch so that a full otable entry is not required:

- If the field access is to a class that within the same compilation unit and
has no superclasses except Object, or all its superclasses are also within the
same compilation unit, then direct dispatch can be used - no otable entry. This
assumes the size of java.lang.Object doesn't change, but I think thats a
reasonable assumption.

- If the field access is to a class within the same compilation unit but which
extends a class in a different compilation unit, then a shortcut dispatch can be
used. We only need to look up the base offset of the object, ie the size of its
superclass. The fixed offset of the object within the current class would then
be added to this offset to find the address of the object. 

The first case is clearly faster in all cases, but the second case isn't so
clear cut since it involves an extra add. However it would reduce the amount of
otable symbol data required and increase sharing of otable entries - when
multiple fields are loaded from the same class, only a single otable load would
be required.

Assuming these dispatch options are used, special cases would typically not be
required within the runtime as inner class field accesses are usually within the
same complation unit. Its conceivable, however, that an inner class could end up
in a different compilation unit from its parent when compiling from bytecode, so
we'd still need to solve this problem for that case.

The best solution is probably to support class metadata attributes for native
code. Specifically, the "InnerClasses" attribute. The runtime can then check
this attribute when performing field access checks and adjust for inner classes