[Pharo-dev] GildaVM - a Non-Blocking I/O Architecture for the Cog VM
btc at openinworld.com
Thu Nov 21 00:06:12 EST 2019
I saw an interesting tweet on "GildaVM: a Non-Blocking I/O Architecture for
the Cog VM" 
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" 
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
Thus a global lock may only(?) be needed to mutate a shared old-space and
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev