- Pharo-dev - lists.pharo.org

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

by pmissech

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-t… > > [2] > https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle… > >

Nov. 21, 2019

GildaVM - a Non-Blocking I/O Architecture for the Cog VM

by Ben Coman

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-t… [2] https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle…

Nov. 21, 2019

[Pharo 8.0] Build #992: 5085-Move-clap-into-BaselineOfBaseLibraries-2

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #992 was: SUCCESS. The Pull Request #5175 was integrated: "5085-Move-clap-into-BaselineOfBaseLibraries-2" Pull request url: https://github.com/pharo-project/pharo/pull/5175 Issue Url: https://github.com/pharo-project/pharo/issues/5085 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 20, 2019

[Pharo 7.0] Build #174: Backport - Fix nextVersion for cases where an entry with basename only exists inâ¦

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #174 was: SUCCESS. The Pull Request #5122 was integrated: "Backport - Fix nextVersion for cases where an entry with basename only exists inâ¦" Pull request url: https://github.com/pharo-project/pharo/pull/5122 Issue Url: https://pharo.fogbugz.com/f/cases/fix Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 20, 2019

[Pharo 8.0] Build #991: spellCheckAstCore

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #991 was: SUCCESS. The Pull Request #5176 was integrated: "spellCheckAstCore" Pull request url: https://github.com/pharo-project/pharo/pull/5176 Issue Url: https://github.com/pharo-project/pharo/issues/spellCheckAstCore Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 20, 2019

[Pharo 8.0] Build #990: Replace-assert-equals-from-Morphic

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #990 was: SUCCESS. The Pull Request #5171 was integrated: "Replace-assert-equals-from-Morphic" Pull request url: https://github.com/pharo-project/pharo/pull/5171 Issue Url: https://github.com/pharo-project/pharo/issues/Replace Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 19, 2019

[Pharo 8.0] Build #989: Replace-assert-equals-from-packages-starting-with-J-and-K

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #989 was: SUCCESS. The Pull Request #5170 was integrated: "Replace-assert-equals-from-packages-starting-with-J-and-K" Pull request url: https://github.com/pharo-project/pharo/pull/5170 Issue Url: https://github.com/pharo-project/pharo/issues/Replace Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 19, 2019

Pharo Techtalk Nov 21

by Marcus Denker

Hi, Next techtalk will be *this* week (Nov 21): Topic: Discussion around Contributing to Pharo8 The idea is to discuss on Discord and may do some examples liveâ¦ Calendar entry: https://association.pharo.org/event-3419546 (sorry for the late announceâ¦ )

Nov. 19, 2019

[Pharo 8.0] Build #988: Replace-assert-equals-from-packages-starting-with-H

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #988 was: FAILURE. The Pull Request #5169 was integrated: "Replace-assert-equals-from-packages-starting-with-H" Pull request url: https://github.com/pharo-project/pharo/pull/5169 Issue Url: https://github.com/pharo-project/pharo/issues/Replace Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 19, 2019

Re: [Pharo-dev] AbstractEnvironmentTestCase

by Sven Van Caekenberghe

> On 19 Nov 2019, at 12:27, ducasse <stepharo(a)netcourrier.com> wrote: > > > >> On 19 Nov 2019, at 11:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> AbstractEnvironmentTestCase exists only in Pharo 8, tracking this with STON (from changes in Pharo 8) gives me tests that can no longer be loaded in Pharo 7 (or versions before that). >> >> At least AbstractEnvironmentTestCase should be back ported to Pharo 7. >> >> Apart from that, I don't think this is a good change (since it breaks backwards compatibility >> too much). > > I do not agree. Well, external code cannot write tests that confirms to the requirements of both versions. >> Why do all Smalltalk>>#at: references have to be removed ? The way I see it, Smalltalk>>#at: could be rewritten to dynamically use a different environment, if that is set up earlier, using a DynamicVariable. Similarly, #asClass could be implemented to follow the same path. > > Because if one day we want to have modules and environment better to have a system that does not point to > global variables. > We should not refer to global variables. But eventually, the reference has to be resolved and it has a name. I am familiar with packages in common lisp, is it like that ? Is there a document that describes these issues more clearly ? The plan going forward ? > Stef > > >> >> Or am I wrong ? >> >> Sven

Nov. 19, 2019