[Vm-dev] A stab at explaining Spur

[Eliot Miranda]

Hi Ken,

Sent from my iPhone

> On Aug 13, 2015, at 4:56 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> 
> 
> Greetings,
> 
> I would think that another option is to replace all the methods in the old class with "updater" methods and flush the method cache(s).  [old selectors, fixup method(s)].
> 
> The new version of the class has a new class index.
> 
> At any send to an old instance, the updater has access to the calling context and can do the forward to the new intance and re-send the method.
> 
> Usual GC cleanup does the rest.
> 
> Why did you choose to avoid this strategy?  (or am I just misunderstanding?)

Yes, this is a viable strategy (Am I right in thinking GemStone does this?) and a very good question.  My reasons were two-fold.  One, I started from the object representation, wanting the commonality of a single header format between 32- & 64-bits so I thought of the solution to become in that lower-level context.  Two, I wanted as small a delta from the current system as possible to ease adoption and bootstrap.  The approach above rally needs a completely different class builder, and that's a major rewrite of a lot of Smalltalk code.

Perhaps there's a third reason; lazy forwarding was a little crazy but I thought it could work and it had never been done. So I was curious.

But there's no reason why the class-level lazy update approach couldn't be explored.  That's why I'm interested in a project to measure accurately the cost of object table indirection vs lazy forwarding vs no forwarding/slow become.  If lazy forwarding's additional costs are not high (one benchmark slows down by ~ 10%) then re architecting the class builder perhaps isn't as compelling.  But if they're really high then sure, try alternatives.

> 
> Thanks much,
> -KenD