On Mon, Sep 24, 2012 at 3:09 AM, Nick Wellnhofer <[email protected]> wrote:
> We also want to discourage writing code that relies on access to ivars of
> parent classes. Unless it's a really performance-critical part, I'd rewrite
> the method above to use accessors:
One possibility we might consider is facilitating subclass access to the
instance variables of same-parcel ancestors, by adding those instance
variables to the subclass struct.
To illustrate, these class definitions...
parcel Foo;
class Base {
int a;
}
...
parcel Bar;
class Parent inherits Base {
int b;
}
...
parcel Bar;
class Child inherits Parent {
int c;
}
... would yield the following IVARS struct definitions:
struct Foo_Base_IVARS {
int a;
}
struct Bar_Parent_IVARS {
int b;
}
struct Bar_Child_IVARS {
int b;
int c;
}
Arguably, this encourages "inheritance abuse" -- i.e. tight coupling between
parent and child classes -- but only within the confines of a single parcel,
which is a lot less harmful than tight coupling between classes in different
parcels. (I tend to believe that the parcel is the right level of abstraction
for code reuse anyway.) And I think this simplification -- that you only need
to think about a variable's type and not its ancestry when obtaining the
relevant IVARS struct -- addresses at least some of the concerns that Nate
raises.
> It's just a guess, but I think in most cases the global offset can be
> fetched from L1, so the performance hit should only be around 5 cycles per
> method call (double that if we have to go through the GOT). It's the same
> performance hit that we already take for virtual method dispatch. There will
> be added register pressure though, which might be noticable on x86-32.
FWIW, we achieved consensus a while back that we would optimize for 64-bit and
only concern ourselves with compatibility for 32-bit. That informal agreement
hasn't been documented anywhere, but I still think it's a good policy.
Marvin Humphrey
