[Vm-dev] GildaVM - a Non-Blocking I/O Architecture for the Cog VM

Ben Coman btc at openinworld.com
Thu Nov 21 05:06:12 UTC 2019

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
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20191121/12de85db/attachment-0001.html>

More information about the Vm-dev mailing list