Ben: Please make sure that these replies are going to the list!
On Sat, Feb 12, 2011 at 12:50 AM, Ben Kloosterman <[email protected]>wrote: > The Java and C# worlds do fine supporting multiple GCs… there are > server GCs , client GCs , concurrent GC etc. OK they use VMs but I see no > issue with a install a GC and recompile libraries step. > > What you say is true, but deceptively so. The Java and C# world get away with this view because they generate native code on the fly. They avoid the on-file-system code size overhead at the cost of a much higher in-memory code size overhead. And in practice there is very little evidence that the use of multiple GCs is actually beneficial in those scenarios. The main difference between client and server VMs lies in their code optimization strategies. > In the vast majority % of cases I don’t need a concurrent GC ( > especially on the sweep) so why pay for it . I think in the last 10 years on > numerous projects GC pauses have only been an issue once and it was easily > fixed by using static data. > Perhaps. The problem is: you only need one critical counter-example. In any case, I'm not pushing to go for a concurrent GC today or even soon. I'm pushing to ensure that it is *possible* to implement a fully concurrent GC later. > 1. There is no reason to believe that large objects do NOT take > part in cycles. In consequence, ref counting them is not a general solution. > > Large objects are normally just excluded from any GC moves ( well in .NET > and C#) and the memory is often kernel allocated. There only participation > in the GC process is the Mark must check for pointers to and from. > > Yes ref counted large objects can still be in non referenced cycles and > still benefit from a very occasional Mark and Sweep. But that doesn’t mean > they ever need to be moved. > But moving them isn't the issue. The problem lies in the fact that the mark pass over them must be atomic w.r.t. to the mutator threads. You seem to agree with this point later in your note, so I won't belabor it. > That all makes sense but all these schemes require some sort of read > barrier which creates a conditional to check if the object has moved and > follows a link (this is the expensive part ) when do it on any read of a > reference... > Yes. And all of the really clever schemes do a good job of optimizing away the barriers in a whole lot of cases - as we will. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
