<div dir="ltr">I saw an interesting tweet on "GildaVM: a Non-Blocking I/O Architecture for the Cog VM" [1]<div>which shows the VM running multiple interpreter-threads. <br><div>Where is the paper shown on page 23 available?<br></div><div><br></div><div>Side thought, if  "usually, 1% of objects survive their first scavenge" [2]</div><div><div>as a "breadth-first traversal of objects from the remembered table (a table holding all old objects referencing new objects) and the stack"<br></div><div></div></div><div><br></div><div>that implies only a small percentage object mutations were in old space (??)</div><div><br></div><div>which makes wonder if each interpreter-thread had its "own" new-space, </div><div>then scavenging each 

new-space 

could run independently in parallel-native-threads?</div><div>Thus a global lock may only(?) be needed to mutate a shared old-space 

and minimize   .</div><div><br></div><div>This ignores the execution-engine needing to update method-lookup tables. <br></div><div>Could native-threads start with their own copy of a warmed up JIT and then work independently? </div><div><br></div><div>cheers -ben</div><div><br></div><div><br></div><div>[1] <a href="https://www.slideshare.net/esug/gildavm-a-nonblocking-io-architecture-for-the-cog-vm">https://www.slideshare.net/esug/gildavm-a-nonblocking-io-architecture-for-the-cog-vm</a>   </div><div>[2] <a href="https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/">https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/</a></div><div><br></div><div><br></div></div></div>