[Vm-dev] A stab at explaining Spur
eliot.miranda at gmail.com
Fri Aug 14 16:01:12 UTC 2015
Sent from my iPhone
> On Aug 13, 2015, at 4:56 PM, Ken.Dickey <Ken.Dickey at whidbey.com> wrote:
> 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,
More information about the Vm-dev