We have spent some time on concurrent GC, and I now want to shift to multi-threaded GC for a moment in response to something Ben raised.
On Wed, Mar 2, 2011 at 11:41 PM, Ben Kloosterman <[email protected]> wrote: > I see what your saying , you can communicate to the GC like don’t > pause now , or fix this object but this communication needs to be > synchronized ( ie an interlock on a variable) and what if you run lots of > small loops ( eg contains on a collection of strings) each requiring such > communication... > When the application is multi-threaded, these costs are inevitable. It is required that the GC know that no mutator thread is active - or at least that any active mutator threads are operating in a mode that is compatible with simultaneous GC. In such cases, the "usual" solution is to put a GC barrier check on procedure entry, and also one on backward loop branches. When one thread needs to GC, it raises a shared "need to GC" signal. The other threads poll this periodically and voluntarily cooperate. One thread then proceeds to execute the GC. The synchronization requirements on this are not tight - if one thread fails to see the "need to stop" signal until it's next procedure call or loop, that's not fatal. There are a range of techniques for reducing synchronizations, including using region analysis to differentiate between per-thread and shared heaps - synchronization is only required on a shared-heap collection. It is also true that full synchronization is *not* required unless a relocation is needed. For example, it is completely reasonable to use size-partitioned, non-relocated regions for small objects, reserving relocation for larger objects (which, note, are allocated with much lower frequency). And there are lots of ways in which effect-aware compilation can assist this. Having the compiler emit "hazard brackets" into the code stream of the form "this thread is executing in a region that does [not] touch any relocatable objects" is in and of itself a major win. 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. 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. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
