Here's what I got out of the article: * They are inserting special x86 instructions around object access JIT output instructions to "trap" uses of references t

Here's what I got out of the article: * They are inserting special x86 instructions around object access JIT output instructions to "trap" uses of references to objects that had cleanup/relocation in progress. The trap works around the work in progress to "heal" the references in rare instances, usually allowing branch prediction on the x86 to simply fall through. * It almost sounds like part of the relocation work by the GC used a mechanism not unlike "transactional memory" to either "commit" a block of moves of active objects, or roll them back in case of a conflict caused by the running application accessing/updating/creating something at an inopportune moment. * One of the diagrams suggests that there are N GC threads corresponding to N application threads. If there is in fact a one-to-one correspondence, rather than just "there are many of both kinds of thread", I wonder if they have thread specific sub-heaps, and employ some kind of processor affinity binding together the application thread and its corresponding GC "shadow" on the same processor? Maybe that's automatic anyway, based on memory region in use? Anyway, localizing these tasks together might avoid processor cache misses. I may have read much more into one of the diagrams than was really meant, though. Even if they don't have thread specific heaps, I think I like the idea of having heaps tied to individual threads, only migrating objects/references to a global heap when they have in fact been shared between threads, or are anchored to some sort of static context. Anybody care to provide an alternate interpretation of some of this?