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 

1)      It requires smaller apps  which while getting more common in the web
and SOA world has been less common in Unix / Research.

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) 

 

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.

 

Every single one requires at least an if  on each reverence . consider a
very common piece of code iterating a collection of references

 

bool contains(object y) 

 {

foreach ( var x in collection) 

     If ( x== y )

            return true;

return false; 

 

}

 

becomes 

 

bool contains(object y) 

 {

foreach ( var x in collection) 

{

If ( x.GCTodo)

     DoSomething();

     If ( x== y )

            return true;

}

return false; 

}

 

A performance difference of close to 100%  even if the if is always false.
While an extreme example , in the total execution if may be in the region of
3-5 %  which means a trivial Mark and sweep will beat you  in most public
language tests ( which are poor and short lived) .

 

Ben

_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev

Reply via email to