>Shap Wrote: >So why don't commonly used collectors do these things as a matter of routine? In my opinion, there are several reasons: >1. There is a presumption, driven by concerns over performance, that any GC'd system is supported by a body of plugin code that is written in C or C++ code. >2. There is a further presumption no cooperation can be had from the C/C++ compiler. >I believe that both of these assumptions are incorrect - or at least that they can be made incorrect on the platforms that are of greatest interest to me. In consequence, I am interested in various classes of compiler/runtime collaborations that are not of interest in the current VM-based language community.
Correcting 1 is something BitC is almost designed for. I think the main reason here is its hard to write an efficient GC in C# or Java . You end up with code like in Singularity. You also have the toolset issue of needing a GC before you can write the code since these languages cant run without a GC For 2. LLVM has hooks though mainly in their VM you can add them to the compiler. >But I'm getting away from my point. You can see that multi-threading can't be done without compiler involvement, and that the concerns are quite different from those of truly concurrent collection methods. Yes there are a number of issues here though that I havent seen much addressed publicly . The relationship you talked about between local Heaps and shared heaps and multi threaded pauseless GC raises a number of questions. Eg - A local heap can just have the nursery allocate memory by incrementing a pointer , there is no locking or anything this is very fast and faster than generic malloc applications. How do Nurseries work with Concurrent -Multithreaded and possibly pause less GCs? - Moving local to shared when it becomes shared or analyzing this (this you already mentioned ) -If you have a ( almost) pauseless concurrent GC why not have one system wide ? ( lock contention vs bigger memory vs one app domination allocations vs safety etc) - If not a shared GC why not a system wide nursery ( or can processes share in a memory domain ?) , what is the trade of between CAS incremented pointer vs local nursery with no cas vs a system wide one ( using CAS) but having to manage moving the object to process Generational stores. Allocating 500 Meg of strings with there normal very short duration would seem quite good or alternatively you could save memory and prevent the wastage you normally get with 1 nursery per process. - In the case of a system wide Nursery To improve concurrency do you have 2 so when one is full a new one is immediately allocated and the old one can immediately be parsed for promotion to local generations. Ben _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
