On Wed, Feb 16, 2011 at 12:23 AM, Jonathan S. Shapiro <[email protected]>wrote:
> 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. > I can say about mono and this is not entirely true. We support multiple collectors that require write barriers in static compilation mode since the WB code in the mutator is the same regardless of the collector. The only two issues are that WB are slower in PIC mode and that all modules must, obviously, use the same barrier. > 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. > > The single most common reason for multiple GCs are latency oriented versus throughput oriented workloads. The first requires a lot to happen concurrently with the mutator, the later is best served with a STW style collector.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
