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