I dont think the fact its not in the kernel is a big reason either ... worst case you could write a kernel module or driver and pass it the data to do the same thing ... less elegant but would work .
Jonothan Singularity had like 8 different types of GCs did they learn anything about switching collectors ? That said who is to say that the Azul collector is not 50% slower.,.. there is very little information about this.. Im sure you can build some syncronised GC with safe spots with minimal pauses but can you do it and not trash cache hits and generating lots of context switches.. Such a GC is still usefull for a large amount of data... but it becomes attractive to use a 2nd allocator for other things and communicating between them which is what David was saying in terms of taking the load of the CG. I can see it as say managing the gen 2 ,, Re concurrent GCs yes i prefer to use the term pausless. there are optomizations though in the .NET concurent GC the .NET one does it in parralel for gen 2 ( they state that gen 0 and 1 collections are so fast that its pointless) . And since no new items can enter Gen 2 ( only references from earlier colelction) its not that hard . Also these types of collectors run much better in the real world where there are more low work times then micro benches ...where there is no down time and once a collection is required you stop the processing . David had a 3D C# game he was going to try on this collector and was wondering how it went. I also think the art of memory management is still usefull with GC .. but little used , where in C it is often used .. if you test it and create too many objects reduce it .. eg if you have a non array linked list reuse your nodes , if you have vertex buffers or buffer[] reuse them . On Tue, Jul 16, 2013 at 12:03 PM, Jonathan S. Shapiro <[email protected]>wrote: > All: > > Just so it's clearly said, David and I agree that there is no single GC > algorithm known that is ideal for all cases, and that there exist > pathological cases for all known GC algorithms (just as there do for > managed storage). I'm less concerned about the kernel changes required by > the Azul collector and its friends than David is. The Linux crew was not > helpful in admitting those changes, and the Azul crew didn't do a good job > of getting buy-in. Both of those are solvable problems. > > > Jonathan > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
