Magma on 3.7 report

[Chris Muller]

> Shouldn't then objects and oids usually have the same size?
 
 This is the question that finally led me to clarity.  I had assumed they did indeed have the same size, and the 2x threshold was based on that assumption.  But where the edges of the materialized domain terminate at proxys, those proxys are values in the 'objects' WeakValue but never keys in 'oids' because #hash would cause them to materialize (so I don't even try).  
 
 Magma keeps the proxy's canonicalized as values in 'objects' so identity comparisons will have a chance to work (since == is not overridable by the proxy).
 
 It just so happens the model in the SqueakSource case had enough proxy's that it easily trumped the 2x threshold, even though there weren't any garbage entries!  A better check for need-to-clean-up is a great idea.
 
 So I have incorporated the great idea of your improvement and then taken it one more step.  The new 3x threshold suited your scenario by luck really.  Perhaps on a SSProject with 2000 versions, it would be enough proxies to cause the 3x threshold to kick in and, while the "open-coded" anyIsNil check is as fast as it can be, it could be a 300-thousand element enumeration getting called a lot.
 
 Therefore, I have been through three different "extensions" of your solution and think I have finally found the best choice.  Just for interest, my first choice was to add a 'proxyCount' to the OidManager.  Proxys are created in only one place, #proxyFor:, and that is where we increment the counter (oh wait, also when we stubOut:).  But it isn't easy to know when proxys "removed" since they can be GC'd.  So, knowing an accurate proxyCount is not easy.
 
 Next, I thought of separating the proxy's into their own WeakValue collection.  But then as they transition to and from non-proxy's they'd be in the wrong place.
 
 Finally, I decided to check, only every 30-seconds, whether at least *half* of the 'object' entries are actually nil.  Since an enumeration is now unavoidable, a WeakValueBTree is now eligible to serve as the 'objects'.  The last choice was whether to continue using the MaWeakValueDictionary or a WeakValueBTree.  The BTree is twice as fast at adding and cleaning, but half as fast at enumerating.  Since the enumeration is done every 30 seconds and adding is done all the time I went with the WeakValueBTree.
 
 > I also fixed the use of instVarNames instead of allInstVarNames in
 > the MaReadStrategy
 
 Another good improvement, thanks!
 
 Its after midnight and I am still running test cases.  I will post all this in the next day or so.
 
 Thanks for your time collaborating, you've really helped out and your still just right out of the gate with Magma.
 
  - Chris