[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RFC: Non-fragile ivars
From: |
David Chisnall |
Subject: |
RFC: Non-fragile ivars |
Date: |
Sat, 31 May 2008 16:21:49 +0100 |
Hi,
Consider the following example:
@interface A : NSObject {
int a;
}
@end
@interface B: A {
int b
int c;
}
@end
B * obj;
At the moment, accesses to objective-c instance variables are
performed by calculating the offset at compile time. Something like
obj->c is translated to something like: (&obj + 12).
With Apple's new break-the-world runtime, they introduced non-fragile
instance variables. I haven't looked at exactly how this works, but
presumably it changes it into (&obj + __A_c_offset), where
__A_c_offset is a global variable filled in at runtime. This means
that:
1) Adding another ivar to A does not affect ivar accesses in A.
2) Reordering the instance variables in B and A will not require a
recompile.
It would be possible to implement this for clang and the GNU runtime
without major changes. I would do it by setting the instance_size
property in the class to 0 - {the real size of instances in just this
class} and set the offsets in the ivar_list to be the offsets from the
superclass (i.e. b would be 0, c would be sizeof(int)). Then modify
the module loader in the runtime to detect this and:
1) Add this size to the size of the superclass.
2) Add the size of the superclass to each of the ivar metadata fields.
The values from the ivar metadata fields would then be used as the
offsets when accessing ivars (these are stored in statically allocated
storage in the data segment and so their addresses are known at
compile time).
The advantages of this would be:
- No code using GNUstep or other frameworks compiled with clang/LLVM
(which we are almost in a position to do) would break if it inherited
from a class whose layout changed.
- No ABI breakage would be needed - code compiled with GCC would still
work on the modified runtime, although the existing constraints on
modification would still apply.
The disadvantages are:
- Currently ivar accesses on most platforms will be a single load /
store instruction in an indirect addressing mode with a constant
offset embedded in the instruction. This would add another load and
addition to every ivar access.
- The extra work that the runtime would do would increase load times
slightly.
So, my questions is, is this worth doing?
David
- RFC: Non-fragile ivars,
David Chisnall <=