February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Azul Pauseless GC

by Andres Valloud

> Is VisualWorks' GC documented somewhere? What kind of documentation do you mean? > However, you might want to read the VEE'05 paper directly, the GC > they use is 'nothing-like' a typical incremental GC. The read-barrier > is the key here, and that is a rather exotic approach due to its > constant overhead on standard systems. I thought they get away with the extra expenditure because they can hide it under a multicore CPU (with the associated mutex section overhead etc), and because they have a compacting IGC that allows their very large images to run. Probably it's a design decision to support huge apps. > So, just in case VisualWorks is actually using something similar, a > reference to a paper or some such would be great. VisualWorks' IGC can mark and sweep incrementally. It does not compact incrementally, either. Somewhere in the source documentation there's an assertion that the read barriers to do that would be painful, so compaction is left to the stop-the-world GC. The rest is pretty similar, including things like the targeted pause times (I'm almost done with an overhaul of that bit of the IGC implementation, actually). Now, if you had a read check to see whether the object body was forwarded or not, then you could also compact incrementally. Unfortunately, checking before every read would probably cost you performance wise (plus: what happens when you want to forward an object body referenced by another thread in registers in the middle of an optimized section?). So, depending on the application, it might be better to avoid stopping the world, while in other cases it might be preferable to skip the IGC completely and using the stop-the-world GC. Finally, I am curious as to what kind of applications need on the order of 1TB of address space in a single "image". Those image scales impose specific performance penalties e.g.: the IGC has to be more complex. I wonder if those apps couldn't be written in a more "agent-like" manner to substitute controlled inter-image communication for the IGC complexities that affect the runtime in a pervasive way. Do you know what kind of apps are those? Andres.

Feb. 28, 2011

Re: [Pharo-project] comments comments comments again

by Dale Henrichs

Stef, Interestingly enough, I have added a class comment to the metacello configuration template class, but when I copy the class, the class comment is not copied ... everything else makes it ... I had hoped that the comment would be present in the copy ... I suppose I could add the comment programmitcally... Dale On Feb 28, 2011, at 12:13 AM, StÃ©phane Ducasse wrote: >> Hi StÃ©ph, >> >> why not implement a tool that takes a package, asks the user to >> identify the most important class comment, and the creates comments >> for all uncommented classes in the package that direct the user to the >> most important class comment? The generated comment could use the >> squeak code hyperlink support so the user just has to double click in >> the generated comment to get to the new comment. How about also >> including in the comment template a suggestion of what kind of >> entry-point documentation you'd like to see? > > I think that it would give the impression that there are comments. > Here my point was: "let us think 1 s about what is the key information a user would need? > oh of course how to execute the configuration so that it loads" > > So this line should not be that difficult to add > > > To load me, execute > ((Smalltalk globals at: #ConfigurationOfPharo) project version: #stable) load > > Because I'm lost with latest, default, load .... > > We should have tool to use class comments to raise their values. > I hope soon that we will have a SmalltalkDoc up and running. > > > Stef > >

Feb. 28, 2011

Re: [Pharo-project] Pharo 1.2 broken on Hudson due to XMLSupport changes

by Otto Behrens

Johan, > The changes you made to the configuration mean that the XMLParser packages are fetched from the gemsource repository for *all* platforms, and not only for GemStone. > I don't think this should be the intention. The official code for the XMLParser for Pharo and Squeak are located in a squeaksource repository. My idea actually was to get an XML-Parser package that works on all platforms, which is the case now. I know that the removal of the Observer trait is not nice, but I think it is easier to mainain 1 package that works on Pharo / Squeak as well as GemStone. And when GemStone supports traits, I'd gladly put it back. Cheers Otto

Feb. 28, 2011

[Pharo-project] Issue 3765 in pharo: fixed printPadded

by pharo＠googlecode.com

Status: Fixed Owner: stephane...(a)gmail.com Labels: Milestone-1.3 New issue 3765 by stephane...(a)gmail.com: fixed printPadded http://code.google.com/p/pharo/issues/detail?id=3765 1.0 printPaddedWith: $0 to: 2.1. "'01.0'" 1.0 printPaddedWith: $0 to: 2.2. "'01.00'" 1.0 printPaddedWith: $0 to: 2.3. "'01.00'" <-- wrong 1.0 printPaddedWith: $0 to: 2.4. "'01.000'" <-- wrong 1.0 printPaddedWith: $0 to: 2.5. "'01.00000'" Attachments: printPadded.1.cs 2.8 KB

Feb. 28, 2011

Re: [Pharo-project] shout for pharo 1.2: Please help.

by laurent laffont

Thank you very much Dale for explanations. Laurent. On Mon, Feb 28, 2011 at 9:11 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > On Feb 27, 2011, at 11:56 PM, laurent laffont wrote: > > > On Mon, Feb 28, 2011 at 8:40 AM, Dale Henrichs <dhenrich(a)vmware.com > <mailto:dhenrich@vmware.com>> wrote: > Pharo 1.0-beta2 _is_ loading Shout 1.2.2 ... that's the one without > ShoutWorkspace, which I think is correct ... so ProfStef is okay ... > > BTW, validation doesn't check whether versions match or not ... if Shout > had a symbolic version defined for Pharo1.2, then I would say that you > should use #stable ... so that you can track the "approved version of shout > for Pharo1.2", however if your project is tightly coupled to Shout then I > would use a literal version number ... > > OK. So now > > (ConfigurationOfProfStef project version: '1.6') load. > > will load Shout 1.2.2. > > > 1/ if I have: > ConfigurationOfProfStef 1.6 -> Shout 1.3 > ConfigurationOfPharo -> Shout 1.2, ProfStef 1.6 > > which Shout will be loaded then ? > > Metacello always goes with the latest version (okay a project can change > it's rule, but the default rule is >=). > > So Shout 1.3 will be loaded ... it's one of the reasons that symbolic > versions were added: so that projects that need to have Shout loaded can > just specify #stable and they don't have to worry about which platform or > which version of Pharo the project is being loaded into ... you'll get the > "correct version" ... > > > > 2/ if I have > ConfigurationOfProfStef 1.6 -> Shout #stable > > and then a new #stable release of Shout 1.8 breaks compatibility with > ProfStef. I suppose ConfigurationOfProfStef 1.6 won't work anymore ? > > If Shout can break your application, then you have a tight coupling to > Shout and you need to worry about which version you are using ... Seaside3.0 > and Grease are tightly coupled.... > > I don't the specifics of your implementation, but I assume that ProfStef > just wants syntax highlighting for the workspaces then you have a loose > coupling and useing #stable should work... in this case, if syntax > highlighting breaks it isn't really ProfStef's fault ... more likely someone > should _not_ have specified Shout 1.8 as stable:) ... > > > PS: I've gone through all Metacello help included in Pharo 1.2 recently - > very cool to have this. However I've just checked and it seems there's no > explanation on dependency on symbolic versions. > > IN my documentation I have tried to say what I know to be true:) The exact > usage model for symbolic versions hasn't become completely clear ... 2 > months ago, I figured that symbolic versions should be used everywhere, but > I have backed off that and recommend that symbolic versions be used in > literal versions when there is a loose coupling between the projects. > > In baseline versions, I recommend that you certainly use either > #bleedingEdge for tightly coupled projects or #stable for loosely coupled > projects that way you can limit the exposure you have when using baseline > versions to load the latest versions of everything ... #stable will just get > you the known working version ... > > I've been threatening to write a post about that, but I am finding that I > am buried with work,so the documentation suffers:) > > Dale > >

Feb. 28, 2011

Re: [Pharo-project] comments comments comments again

by StÃ©phane Ducasse

> Hi StÃ©ph, > > why not implement a tool that takes a package, asks the user to > identify the most important class comment, and the creates comments > for all uncommented classes in the package that direct the user to the > most important class comment? The generated comment could use the > squeak code hyperlink support so the user just has to double click in > the generated comment to get to the new comment. How about also > including in the comment template a suggestion of what kind of > entry-point documentation you'd like to see? I think that it would give the impression that there are comments. Here my point was: "let us think 1 s about what is the key information a user would need? oh of course how to execute the configuration so that it loads" So this line should not be that difficult to add To load me, execute ((Smalltalk globals at: #ConfigurationOfPharo) project version: #stable) load Because I'm lost with latest, default, load .... We should have tool to use class comments to raise their values. I hope soon that we will have a SmalltalkDoc up and running. Stef

Feb. 28, 2011

Re: [Pharo-project] shout for pharo 1.2: Please help.

by Dale Henrichs

On Feb 27, 2011, at 11:56 PM, laurent laffont wrote: On Mon, Feb 28, 2011 at 8:40 AM, Dale Henrichs <dhenrich(a)vmware.com<mailto:dhenrich@vmware.com>> wrote: Pharo 1.0-beta2 _is_ loading Shout 1.2.2 ... that's the one without ShoutWorkspace, which I think is correct ... so ProfStef is okay ... BTW, validation doesn't check whether versions match or not ... if Shout had a symbolic version defined for Pharo1.2, then I would say that you should use #stable ... so that you can track the "approved version of shout for Pharo1.2", however if your project is tightly coupled to Shout then I would use a literal version number ... OK. So now (ConfigurationOfProfStef project version: '1.6') load. will load Shout 1.2.2. 1/ if I have: ConfigurationOfProfStef 1.6 -> Shout 1.3 ConfigurationOfPharo -> Shout 1.2, ProfStef 1.6 which Shout will be loaded then ? Metacello always goes with the latest version (okay a project can change it's rule, but the default rule is >=). So Shout 1.3 will be loaded ... it's one of the reasons that symbolic versions were added: so that projects that need to have Shout loaded can just specify #stable and they don't have to worry about which platform or which version of Pharo the project is being loaded into ... you'll get the "correct version" ... 2/ if I have ConfigurationOfProfStef 1.6 -> Shout #stable and then a new #stable release of Shout 1.8 breaks compatibility with ProfStef. I suppose ConfigurationOfProfStef 1.6 won't work anymore ? If Shout can break your application, then you have a tight coupling to Shout and you need to worry about which version you are using ... Seaside3.0 and Grease are tightly coupled.... I don't the specifics of your implementation, but I assume that ProfStef just wants syntax highlighting for the workspaces then you have a loose coupling and useing #stable should work... in this case, if syntax highlighting breaks it isn't really ProfStef's fault ... more likely someone should _not_ have specified Shout 1.8 as stable:) ... PS: I've gone through all Metacello help included in Pharo 1.2 recently - very cool to have this. However I've just checked and it seems there's no explanation on dependency on symbolic versions. IN my documentation I have tried to say what I know to be true:) The exact usage model for symbolic versions hasn't become completely clear ... 2 months ago, I figured that symbolic versions should be used everywhere, but I have backed off that and recommend that symbolic versions be used in literal versions when there is a loose coupling between the projects. In baseline versions, I recommend that you certainly use either #bleedingEdge for tightly coupled projects or #stable for loosely coupled projects that way you can limit the exposure you have when using baseline versions to load the latest versions of everything ... #stable will just get you the known working version ... I've been threatening to write a post about that, but I am finding that I am buried with work,so the documentation suffers:) Dale

Feb. 28, 2011

Re: [Pharo-project] shout for pharo 1.2: Please help.

by laurent laffont

On Mon, Feb 28, 2011 at 8:40 AM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Pharo 1.0-beta2 _is_ loading Shout 1.2.2 ... that's the one without > ShoutWorkspace, which I think is correct ... so ProfStef is okay ... > > BTW, validation doesn't check whether versions match or not ... if Shout > had a symbolic version defined for Pharo1.2, then I would say that you > should use #stable ... so that you can track the "approved version of shout > for Pharo1.2", however if your project is tightly coupled to Shout then I > would use a literal version number ... > OK. So now (ConfigurationOfProfStef project version: '1.6') load. will load Shout 1.2.2. 1/ if I have: ConfigurationOfProfStef 1.6 -> Shout 1.3 ConfigurationOfPharo -> Shout 1.2, ProfStef 1.6 which Shout will be loaded then ? 2/ if I have ConfigurationOfProfStef 1.6 -> Shout #stable and then a new #stable release of Shout 1.8 breaks compatibility with ProfStef. I suppose ConfigurationOfProfStef 1.6 won't work anymore ? PS: I've gone through all Metacello help included in Pharo 1.2 recently - very cool to have this. However I've just checked and it seems there's no explanation on dependency on symbolic versions. Laurent > Dale > On Feb 27, 2011, at 11:19 PM, laurent laffont wrote: > > Hi, > > I've remembered that ProfStef has a dependency on Shout. In version 1.6 > (current stable) I have: > > spec for: #pharo do: [ > spec > project: 'Shout' with: '1.2.2'; > > can it be a problem ? > > If I remove it Metacello validator raises a critical warning. > > Laurent > > > On Mon, Feb 28, 2011 at 8:07 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: > Yes but pharo was still loading the version 1.2.1 > So normally the latest configurationOfPharo and shout are fixed and > working. > Can you confirm that? > > Stef > On Feb 28, 2011, at 5:30 AM, Francisco Ortiz PeÃ±aloza wrote: > > > Hi Stef don't know if you already solve this, i created a 1.2.2 > > version of ConfigurationOfShout referencing some changes i made to > > shout to work with Editor changes. > > > > There're like five new versions since that and it's currently working > > with PharoCore 1.2 cause i tested a lot :) > > > > Cheers, > > Francisco > > > > > > > > On Sun, Feb 27, 2011 at 7:26 PM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: > >> Ok > >> For me I just wanted to check if I can load shout. > >> Now it is just breaking on Dev Toolset>> > >> SHWorkspace open. > >> > >> I still do not understand how the correct version of shout was loaded > before. > >> Since Pharo was referencing 1.2.1 which was referencing jannik old > version > >> and the one with the fix of benjamin was not loaded. > >> > >> So I should adapt the baseline to load the correct test in 1.2.2 > >> The problem is that testing all the setup takes 35 min. > >> > >> Stef > >> > >> > >>> So Stef, I looked at ConfigurationOfPharo-StephaneDucasse.139 and I > noticed that you commented out some package specs for 1.2-beta2 ... you need > to be aware that commenting them out does not prevent those packages from > being loaded .... > >>> > >>> To make structural changes you need to remove the package spec from > 1.2-beta2 _and_ remove the package from 1.2-baseline. > >>> > >>> The specification for Shout Tests in 1.2-beta2 specifies the mcz file > to load. By commenting out the spec and leaving the spec in 1.2-baseline you > are telling Metacello to load the latest version of the Shout Tests > package.. > >>> > >>> Since 1.2-baseline is already shared by multiple versions, one way to > remove Shout Tests for version 1.2-beta2, is to create a 1.2-beta2-baseline > that does not include Shout Tests... > >>> > >>> You comment says that you don't know which version of the Shout Tests > to load, but by looking at 1.2-beta2-baseline, Shout Tests is referencing > the same project as Shout with a different load directive so it is correct > to use the save version as Shout. > >>> > >>> In a normal case I would recommend that you use the validator to look > at the configuration and fix those issues, but there _are_ a number of > validation issues with ConfigurationOfPharo already (which depending on what > other changes you have made might actually be contributing to the problem > ... There were also validation issues ConfigurationOfShout ... so you might > have hit a "perfect storm" of validation issues .. > >>> > >>> I have merged your changes into my working copy and I'll be doing a > test load shortly so perhaps I'll be able to observe some of the problems > first hand .. > >>> > >>> Dale > >>> > >>> On Feb 27, 2011, at 8:30 AM, StÃ©phane Ducasse wrote: > >>> > >>>> Ok > >>>> I do not understand how it loaded before because > >>>> I got a duplicate instance warning raised (even if the class > loaded was empty - I do not get it) > >>>> So I remove the empty package, fixing the version and the > baseline... > >>>> > >>>> Now I have the decompiler popping windows.... problem > >>>> Today this is tedious. > >>>> For a fix of 1 min I already spent 2 hours to try to load a > configuration. > >>>> > >>>> Stef > >>>> > >>>> > >>>>> Stef, > >>>>> > >>>>> I will try to take a look at your issue today along with testing out > the configuration fixes I have pending ... both Pharo and Shout had > configuration issues, but I can't say that your particular issue is related > ... yet. > >>>>> > >>>>> Dale > >>>>> > >>>>> On Feb 27, 2011, at 7:57 AM, StÃ©phane Ducasse wrote: > >>>>> > >>>>>> Hi guys > >>>>>> > >>>>>> I modified > >>>>>> > >>>>>> version 1.2.1 of ConfigurationOfShout to load my version > >>>>>> Shout-sd.101 (apparently lot of comments were removed between > Benjamin.100 and Benjamin.101 - strange) > >>>>>> > >>>>>> > >>>>>> In ConfigurationOfPharo there is > >>>>>> > >>>>>> project: 'Shout' with: '1.2.1'; > >>>>>> > >>>>>> > >>>>>> Now in ConfigurationOfShout there are > >>>>>> > >>>>>> version122: spec <version: '1.2.2' imports: #('1.1-baseline')> spec > for: #common do: [ spec blessing: #development. spec author: 'Francisco > Ortiz PeÃ±aloza'. spec description: 'Shout Changes for 1.2 using new > SmalltalkEditor'. ]. > >>>>>> > >>>>>> > >>>>>> version121: spec > >>>>>> <version: '1.2.1' imports: #('1.1-baseline')> > >>>>>> > >>>>>> spec for: #common do: [ > >>>>>> spec blessing: #development. > >>>>>> spec author: 'Stephane Ducasse'. > >>>>>> spec description: 'Shout for 1.2'. > >>>>>> ]. > >>>>>> > >>>>>> > >>>>>> When I load the latest stable of Pharo > >>>>>> > >>>>>> ((Smalltalk globals at: #ConfigurationOfPharo) project version: > #stable) load > >>>>>> > >>>>>> I get an error due to a duplicate (probably the instance variable of > pluggableShout.....). > >>>>>> Probably loading the wrong package. > >>>>>> > >>>>>> So I do not know what to do and lost my time. > >>>>>> > >>>>>> Stef > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > > > > > >

Feb. 28, 2011

Re: [Pharo-project] shout for pharo 1.2: Please help.

by Dale Henrichs

Pharo 1.0-beta2 _is_ loading Shout 1.2.2 ... that's the one without ShoutWorkspace, which I think is correct ... so ProfStef is okay ... BTW, validation doesn't check whether versions match or not ... if Shout had a symbolic version defined for Pharo1.2, then I would say that you should use #stable ... so that you can track the "approved version of shout for Pharo1.2", however if your project is tightly coupled to Shout then I would use a literal version number ... Dale On Feb 27, 2011, at 11:19 PM, laurent laffont wrote: Hi, I've remembered that ProfStef has a dependency on Shout. In version 1.6 (current stable) I have: spec for: #pharo do: [ spec project: 'Shout' with: '1.2.2'; can it be a problem ? If I remove it Metacello validator raises a critical warning. Laurent On Mon, Feb 28, 2011 at 8:07 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: Yes but pharo was still loading the version 1.2.1 So normally the latest configurationOfPharo and shout are fixed and working. Can you confirm that? Stef On Feb 28, 2011, at 5:30 AM, Francisco Ortiz PeÃ±aloza wrote: > Hi Stef don't know if you already solve this, i created a 1.2.2 > version of ConfigurationOfShout referencing some changes i made to > shout to work with Editor changes. > > There're like five new versions since that and it's currently working > with PharoCore 1.2 cause i tested a lot :) > > Cheers, > Francisco > > > > On Sun, Feb 27, 2011 at 7:26 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >> Ok >> For me I just wanted to check if I can load shout. >> Now it is just breaking on Dev Toolset>> >> SHWorkspace open. >> >> I still do not understand how the correct version of shout was loaded before. >> Since Pharo was referencing 1.2.1 which was referencing jannik old version >> and the one with the fix of benjamin was not loaded. >> >> So I should adapt the baseline to load the correct test in 1.2.2 >> The problem is that testing all the setup takes 35 min. >> >> Stef >> >> >>> So Stef, I looked at ConfigurationOfPharo-StephaneDucasse.139 and I noticed that you commented out some package specs for 1.2-beta2 ... you need to be aware that commenting them out does not prevent those packages from being loaded .... >>> >>> To make structural changes you need to remove the package spec from 1.2-beta2 _and_ remove the package from 1.2-baseline. >>> >>> The specification for Shout Tests in 1.2-beta2 specifies the mcz file to load. By commenting out the spec and leaving the spec in 1.2-baseline you are telling Metacello to load the latest version of the Shout Tests package.. >>> >>> Since 1.2-baseline is already shared by multiple versions, one way to remove Shout Tests for version 1.2-beta2, is to create a 1.2-beta2-baseline that does not include Shout Tests... >>> >>> You comment says that you don't know which version of the Shout Tests to load, but by looking at 1.2-beta2-baseline, Shout Tests is referencing the same project as Shout with a different load directive so it is correct to use the save version as Shout. >>> >>> In a normal case I would recommend that you use the validator to look at the configuration and fix those issues, but there _are_ a number of validation issues with ConfigurationOfPharo already (which depending on what other changes you have made might actually be contributing to the problem ... There were also validation issues ConfigurationOfShout ... so you might have hit a "perfect storm" of validation issues .. >>> >>> I have merged your changes into my working copy and I'll be doing a test load shortly so perhaps I'll be able to observe some of the problems first hand .. >>> >>> Dale >>> >>> On Feb 27, 2011, at 8:30 AM, StÃ©phane Ducasse wrote: >>> >>>> Ok >>>> I do not understand how it loaded before because >>>> I got a duplicate instance warning raised (even if the class loaded was empty - I do not get it) >>>> So I remove the empty package, fixing the version and the baseline... >>>> >>>> Now I have the decompiler popping windows.... problem >>>> Today this is tedious. >>>> For a fix of 1 min I already spent 2 hours to try to load a configuration. >>>> >>>> Stef >>>> >>>> >>>>> Stef, >>>>> >>>>> I will try to take a look at your issue today along with testing out the configuration fixes I have pending ... both Pharo and Shout had configuration issues, but I can't say that your particular issue is related ... yet. >>>>> >>>>> Dale >>>>> >>>>> On Feb 27, 2011, at 7:57 AM, StÃ©phane Ducasse wrote: >>>>> >>>>>> Hi guys >>>>>> >>>>>> I modified >>>>>> >>>>>> version 1.2.1 of ConfigurationOfShout to load my version >>>>>> Shout-sd.101 (apparently lot of comments were removed between Benjamin.100 and Benjamin.101 - strange) >>>>>> >>>>>> >>>>>> In ConfigurationOfPharo there is >>>>>> >>>>>> project: 'Shout' with: '1.2.1'; >>>>>> >>>>>> >>>>>> Now in ConfigurationOfShout there are >>>>>> >>>>>> version122: spec <version: '1.2.2' imports: #('1.1-baseline')> spec for: #common do: [ spec blessing: #development. spec author: 'Francisco Ortiz PeÃ±aloza'. spec description: 'Shout Changes for 1.2 using new SmalltalkEditor'. ]. >>>>>> >>>>>> >>>>>> version121: spec >>>>>> <version: '1.2.1' imports: #('1.1-baseline')> >>>>>> >>>>>> spec for: #common do: [ >>>>>> spec blessing: #development. >>>>>> spec author: 'Stephane Ducasse'. >>>>>> spec description: 'Shout for 1.2'. >>>>>> ]. >>>>>> >>>>>> >>>>>> When I load the latest stable of Pharo >>>>>> >>>>>> ((Smalltalk globals at: #ConfigurationOfPharo) project version: #stable) load >>>>>> >>>>>> I get an error due to a duplicate (probably the instance variable of pluggableShout.....). >>>>>> Probably loading the wrong package. >>>>>> >>>>>> So I do not know what to do and lost my time. >>>>>> >>>>>> Stef >>>>> >>>>> >>>> >>>> >>> >>> >> >> >>

Feb. 28, 2011

Re: [Pharo-project] Azul Pauseless GC

by Stefan Marr

Hi Andres: On 28 Feb 2011, at 08:01, Andres Valloud wrote: > FWIW, the "pauseless" feature of the algorithm sounds very close (if not exactly) like VisualWorks' incremental GC, modulo the multithreading. Is VisualWorks' GC documented somewhere? However, you might want to read the VEE'05 paper directly, the GC they use is 'nothing-like' a typical incremental GC. The read-barrier is the key here, and that is a rather exotic approach due to its constant overhead on standard systems. So, just in case VisualWorks is actually using something similar, a reference to a paper or some such would be great. Thanks Stefan > > On 2/26/11 9:46 , StÃ©phane Ducasse wrote: >> Thanks damien for the link :) >> >> Begin forwarded message: >> >>> Nice explanation of the Azul Pauseless GC (easier than the paper :) >>> http://www.infoq.com/articles/azul_gc_in_detail >> >> >> > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Feb. 28, 2011