MMtk uses it eg
“I'm currently leaning towards building some kind of concurrent collector for MMTk” which Jeremie was referring to and is the only real competitor to the CLR at this point … yes you can build your own GCs but these are not really the LLVM one as its just a few very basic hooks then. And note it is not just the shadow stack but the whole easy to bolt in GC leads to one that is not very competitive. And I don’t think Bitc has time at the moment to write its own , when it does it will probably be a mostly pause less one … And, regardless of whether you use compiled stack maps or the shadow stack, the actual collector -- the trickiest bit by far -- is still up to you. Which is as it should be. High-performance garbage collectors are strongly tied to a language implementation's object model and semantics. You might get decent performance from another language's GC, but you'll never get great performance, especially on pause times. And especially for BitC, it seems like pause times are much more critical than raw throughput... Agree …but the poster was referring to MMtk…. If you want decent performance now on a Sandbox the CLR is better ( not just because of the GC) , Bitc is also likely to use LLVM and its own GC later for fully compiled code ( I don’t think its practical to write your own compiler so your choice boils down to LLVM or compile via gcc ) . If Jeremie wants to implement a BitC pauseless collector for LLVM that would be great but I don’t think its what he had in mind. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
