This certainly sounds like an interesting idea with is worth considering. I'd like to hear from some of the other core devs regarding their opinions on this.
GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer ----- Original Message ---- From: David Chisnall <[EMAIL PROTECTED]> To: Discuss-gnustep GNUstep <[email protected]> Sent: Saturday, May 31, 2008 11:21:49 AM Subject: RFC: Non-fragile ivars 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 _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
