Re: RFC: Non-fragile ivars

[address@hidden]

On 31 Mai, 17:28, Gregory John Casamento <greg_casame...@yahoo.com>
wrote:
> 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 <thera...@sucs.org>
> To: Discuss-gnustep GNUstep <discuss-gnus...@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?

If one has to change a compiler and runtime anyway, improvements in
stability can be easily introduced.

As far as I remember some discussion on this, the Apple runtime does
it mainly the same way by adding one more level of indirection. The
classical "solution" to this fragility issue was to put everthing
which could change in the future into one iVar 'void
*internalData;'... Therefore, there was already one more level of
indirection - which is no moved from the programmer to the compiler/
runtime. And, the drawback was that subclasses could not directly use
that content and had to call the getters/setters of the superclass
explicitly.

The most prominent area where I think it has practical relevance also
for GNUstop is for subclasses of NSView/NSCell. Some 50% of all
applications use that feature. If we now change something in the
NSView implementation e.g. to improve the drawing engine by caching
mechanisms or implement new attributes/getters/setters, code using
subclasses of NSView must be recompiled. This is quite difficult to
communicate to the users.

So, it removes one level of dependency and potential problems.

My opinion: yes.

Nikolaus