Re: RFC: Non-fragile ivars

[Gregory John Casamento]

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 <theraven@sucs.org>
To: Discuss-gnustep GNUstep <discuss-gnustep@gnu.org>
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
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep