Re: [RFC/PATCH] EOEntity

[Richard Frith-Macdonald]

On Thursday, November 28, 2002, at 04:39  pm, David Ayers wrote:
> > Speaking of other problems ... it's not really a big problem 
> > necessarily, but I think it would be nice to re-implement the 
> > Fault/FaultHandler code somewhat...
> >
> > At the moment objects get morphed into faults by -
> > 1. changing the isa pointer
> > 2. overwriting the next four bytes of ivar data with a pointer to the 
> > fault handler.
> > The second part is a theoretical problem if a class being made into a 
> > fault doesn't actually have any ivars beyond the isa pointer ... this 
> > may not be possible in practice, but I don't like it.
> >
> > Because of this messing with the initial ivars, where an object being 
> > faulted is a garbage collecting object, the linked list of pointers 
> > in the garbage collection is screwed up  - which means that the 
> > faulting mechanism also has to be intimately aware of the GC 
> > mechanism (and hack it to continue working), and also that the GC 
> > mechanism has to work entirely through methods rather than accessing 
> > the linked list pointer ivars directly.  This adds complexity to the 
> > faulting mechanism and makes GC passes quite inefficient.
> >
> > If we used a global map table to map fault objects to their handlers, 
> > we could make an object into a fault simply by changing its isa 
> > pointer and adding it to the mapping.
> > This would mean that the faulting code could be simplified a bit, and 
> > also that the GC could run faster because we would not have 
> > interfered with the linked list pointers.
> >
> > Or am I missing something that means doing that would be a bad idea?
>
> Do you mean that the values of the ivars (the GC-linke list) will 
> effectively exist while the object is a fault and therefor the linked 
> list can still be accessed and manipulated?

Yes.

>  But wouldn't firing the fault later restore the "old/orignal" linked 
> list values?

No ... it would just change the isa pointer.

> That would still mean the fault handler would need to know which ivars 
> to restore so that it will leave the GC ivars alone.  But we wouldn't 
> have to message (i.e. fire) during GC-passes, which is a definate 
> plus.  But maybe you can insure that the fault is fired before any 
> manipulation takes place, then that shouldn't be a problem.

The way I think it *ought* to work is that the collector would do 
everything that can be done by direct ivar manipulation itsself, and 
the fault object would only need to forward a couple of messages to the 
handler (-gcDecrementRefCountOfContainedObjects and 
-gcIncrementRefCountOfContainedObjects).  If garbage collection would 
cause the fault to be deallocated, the dealloc message  would be sent 
to the handler ... which would restore the fault to its original class 
and deallocate it.

For added efficiency, we could have EOFault subclasses, so that if a 
fault is created for an object of a class which dies not override the 
default implementations of those two methods, the fault would know it 
does not need to forward the methods to the handler but can just call 
the default implementations ... with some case we could almost entirely 
avoid objc method invocation overheads during garbage collecting.