Hi David,

David Shaffer wrote:
> This sounds great.  Some implementation hints?  I assume I'd need to
> make the weak entry recognizable by #nonWeakFieldsOf: but I don't
> understand the class format voodoo in that method.   Also it seems that
> the weak slots have to come after the non-weak slots...just a detail but
> is this correct?

Yes, weak slots always come after the fixed slots. On the image side 
this is represented by the weak slots always being indexed (Dan and I 
designed this so that a class could have both "strong" iVars and "weak" 
indexed fields). A good starting point is actually 
ObjectMemory>>finalizeReference: which cleans up all the weak fields in 
an object. If we just replace #signalFinalization: with a type check for 
whether the object is a finalizer or not, and if so, add it to the 
finalization queue we're basically done with the first stage :-)

Checking the class would be done by adding an extra entry (the class) to 
the specialObjectsArray, and then we just need something that looks like 
here (the finalizerList is stored in the splObjects, too):

signalFinalization: oop
   (self fetchClassOf: oop) == self classFinalizer ifTrue:[
     self addLastLink: oop toList: self finalizerList.
     self forceInterruptCheck.
     pendingFinalizationSignals _ pendingFinalizationSignals + 1.
   ].

Oh, and the above is inefficient - we really want the type check to 
happen early in #finalizeReference: since the above is called for each 
slot that got nil-ed in the object (which may be more than one) but it's 
a great starting point.

>> [*1] The easiest way to do this would be to simply clone the object
>> but unfortunately this also has the unbounded memory problem so
>> something a bit more clever might be required. Basically we really
>> want *all* references to the object except from the finalizer to be
>> cleaned up.
> 
> Yes this would be nicer than the "executors" which don't really have
> much to go on.  Why would we copy?  Why not some other color mark for
> object reachable through the weak reference (but not through others, of
> course)?  Then the sweep phase could identify those that are only weakly
> reachable and perform your switcheroo.

Actually (and I only realized that after sending off the previous 
message) there is a significant problem here since you need an extra 
pass to trace the "inside" of the object when you recognize that it 
should be preserved after all. That seems more work than I originally 
thought it would be and tricky work at that.

>> Note that weak arrays or other weak classes wouldn't be affected at
>> all by this since only Finalizers get the notifications - all other
>> weak classes would simply drop the references when they get collected
>> and never get notified about anything.
> 
> Yes I guess that WeakRegistry would be the only class significantly
> impacted by this.  I see a few other senders of addWeakDependent:
> arround but it looks like the effort to move those to this scheme would
> be relatively minimal.

WeakRegistry and other users would be fairly straighforward to deal with 
- they'd just store (strong references to) Finalizer's instead of (weak) 
object references and the finalizer would remove itself from the 
registry. No big deal, really.

Cheers,
   - Andreas