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