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 .
Jonathan 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 ,, Has anybody had a close look at the .NET concurent GC the .NET one runs it in parralel with code execution for gen 2 collect ( they state that gen 0 and 1 collections are so fast that its pointless despite that the latest version can collect 1& 2 while the gen 2 is collecting) 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[] for streaming 1M blccks then 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
