Hi All, I had occasion to compare VW (vw7.7nc) and Spur recently and was pleasantly surprised to see that Spur is on average -40% faster than VW on a large subset of the benchmarks from the shootout (I didn't include three because of Regex syntax issues). Now Spur gets some of its speed from having direct pointers vs VisualWorks' object header/table indirection, but it could get other speedups from various other differences. It would be great to know exactly how much speedup comes from what, and indeed how much cost Sour pays for its lazy become:. I'd like to propose a project to exactly determine the costs of an explicit read barrier and of lazy forwarding compared to no check at all. Spur, part of VMMaker.oscog, is implemented by a hierarchy of classes that implement a 32-bit and a 64-bit memory manager. Spur is a sibling to the old ObjectMemory class that implements the V3 object representation. The current Spur does "lazy forwarding" where two objects are become by cloning each object, making the old versions point to the opposite copy, and relying on send-time checks to lazily follow forwarding pointers when sends to forwarded objects fail a message lookup. The project would create two additional variations on Spur, both of which dispense with the lazy check. One would explicitly test for a forwarding pointers on every access, and one would never check, not need send-time checking either and would reimplement become: like the old ObjectMemory, by scanning the entire heap to exchange all references. These variations could be implemented as subclasses or siblings of Spur. The project isn't trivial because it also means making changes to the JIT, albeit within its framework for multiple object representations. Because this is probably some months' work I can't do it myself but I'm extremely interested in the results and I think it would make a really good paper, e.g. for ISMM, or one of the dynamic language workshops. If what I've said makes any sense at all to any academics out there who are looking for a challenging but nicely contained and far from open ended Masters project then please get in touch and we can see if we can take this any further. _,,,^..^,,,_ best, Eliot