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

pmissech pierre.misse-chanabier at inria.fr
Thu Nov 21 01:22:08 EST 2019


Hi Ben

It was accepted at IWST 2019, so there you go =]


https://esug.github.io/2019-Conference/cfpIWST2019.html

or direct download 
linkhttp://esug.github.io/2019-Conference/articles/2019-08-26-IWST19.zip


Pierre

On 21/11/2019 06:06, Ben Coman wrote:
> 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
>
>
> [1] 
> https://www.slideshare.net/esug/gildavm-a-nonblocking-io-architecture-for-the-cog-vm 
>
> [2] 
> https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-collector/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20191121/4a4f876d/attachment.html>


More information about the Pharo-dev mailing list