discuss-gnustep
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]