Please du not send mi ani mail.
________________________________ From: Jonathan S. Shapiro <[email protected]> To: [email protected]; Discussions about the BitC language <[email protected]> Sent: Wed, March 2, 2011 2:00:52 AM Subject: Re: [bitc-dev] GC collect without stop the world On Sat, Feb 26, 2011 at 12:27 AM, Ben Kloosterman <[email protected]> wrote: >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. > >That doesn’t mean there isn’t a benefit ... >2) Actually it is in use at the moment eg many web sites (ASP.NET and >Java) use a simple .NET GC at the front end , may use a concurrent GC in the >middle and static allocation at the back. Ie the GC is seen as part of the >language / framework and is part of the decision on whether to use those >tools. > ( And note I’m including static allocation as a very valid form of memory >management for a single shared critical component) > I think we are talking past each other. Yes, there is definitely a benefit. The benefit has to be weighed against the costs of version management in the libraries. As long as all the GCs can use the same compilation techniques, you're fine. Once they change the demands on the compilers, you have to deal with versioning. I'm also saying that while there are many types of GCs, the big dividing line seems to be non-blocking versus blocking designs. Within blocking designs, there are GCs that are better for one application or another, but when the outcomes are examined it often turns out that some change in the code generation strategy would eliminate the disparity. Often that change help the application in any case. Not always, but often. So what I'm saying here is that the cost of multiple GCs is low, but the cost of multiple static compilation strategies is high. 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. > >Every single one requires at least an if on each reverence … I like your example very much. It's a wonderful illustration of a bad problem with a pretty simple solution. It's therefore a great example of why optimizers designed to compile non-GCd languages don't do a good job on GC'd code, and why compilation strategies really matter a lot. A performance difference of close to 100% even if the if is always false... Umm. On modern multi-issue processors, assuming a decent compiler, I doubt that very much, but there certainly is a cost, and it's certainly significant. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
