Hi Andres:
On 28 Feb 2011, at 09:41, Andres Valloud wrote: >> Is VisualWorks' GC documented somewhere? > > What kind of documentation do you mean? A paper about the GC algorithm, the name of the algorithm? > >> 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. Their target is/was mainly financial/trade applications hugh heaps, on hugh and expensive custom hardware. Order of 1000cores per box with a 54-core custom chip. >> 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). I guess it is some variation of a three-color incremental mark/sweep? > 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?). That is the whole point of their design. They have a hardware read barrier, and they use traps do make that possible. One of the tricks they are pulling for that is that they return the memory page to the OS, and thus, they run into a trap when ever someone is referring to an old object address. Then, when that occurs they just fix the address to the new one. (as far as I remember...) > 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. As I said, they are after big financial and commerce applications, the stories Cliff Click is usually telling is that if they would need to do a GC in pre-Christmas load situations their customers would lose a lot of sales... Everything is plain old Java, no idea what kind of custom solutions those companies built on top of that. Best regards Stefan -- 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
