Re: RFC: Non-fragile ivars

[Saso Kiselkov]

It would be great to also add this algorithm into +poseAsClass: and
possibly category handling, since that would allow to have posing
classes and categories define their own ivars.

--
Saso

David Chisnall wrote:
> On 3 Jun 2008, at 09:11, Fred Kiefer wrote:
>
>> I like this whole idea a lot, but we will need a bit more performance
>> testing to make sure we understand the consequences.
>>
>> What I did not quite get is where are we going to store the size of
>> the different classes? Perhaps a more detailed outline of the
>> algorithm would help here.
>>
>> Fred
>
> Each class has an instance_size parameter.  This is filled in by the
> compiler, which creates the class statically in the data segment.  It
> also has an array of structures containing the offsets of each
> instance variable from the self pointer.  My proposal is that the
> compiler should be modified so that:
>
> For all classes which are not base classes, instance_size is set to 0
> - the size of the instance variables added for this class.
> The addresses of all instance variables in the metadata structure are
> then set to the offset from the start of the new class.  i.e. the
> first instance variable declared for any class will have offset 0,
> irrespective of the size of the superclass.
>
> The runtime will then be modified so that, on loading a class, it
> checks whether instance_size <= 0 (instance size is currently >=
> sizeof(id), since it always contains at least the isa pointer).  If
> so, then it will set instance_size to super_class->instance_size -
> instance_size (don't forget, instance_size is negative for classes
> supporting non-fragile ivars).  It will then add
> super_class->instance_size to the offset in every ivar.
>
> The module load function will then introspect the runtime to get the
> offset of each instance variable in the class and store it in a
> name-mangled global.  I'd like to be able to get it directly from the
> metadata structure, but I don't think this is possible (although with
> link-time optimisation it might be).
>
> Anyway, I will try implementing this in the fork of the GNU runtime we
> have in the Étoilé repository, and if it seems useful send the patches
> upstream.  I had a chat with Andrew Pinski a while ago, and he's
> (provisionally) willing to accept patches for this but doesn't have
> the time to do it himself.
>
> David
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep