I saw an interesting tweet on "GildaVM: a Non-Blocking I/O Architecture for the Cog VM" [1] which shows the VM running multiple interpreter-threads. Where is the paper shown on page 23 available? Side thought, if "usually, 1% of objects survive their first scavenge" [2] as a "breadth-first traversal of objects from the remembered table (a table holding all old objects referencing new objects) and the stack" that implies only a small percentage object mutations were in old space (??) which makes wonder if each interpreter-thread had its "own" new-space, then scavenging each new-space could run independently in parallel-native-threads? Thus a global lock may only(?) be needed to mutate a shared old-space and minimize . This ignores the execution-engine needing to update method-lookup tables. Could native-threads start with their own copy of a warmed up JIT and then work independently? cheers -ben [1] https://www.slideshare.net/esug/gildavm-a-nonblocking-io-architecture-for-th... [2] https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collec...