> Raoul: The Bacon work is excellent, and I need to read it more carefully - > especially the concurrency part - but the 2.4ms pause times shouldn't have > to be that high. The URC work is also good. For BitC, we're looking at > something more similar to the C4 collector or the Stopless collector. Doing > the Bacon approach really well requires a really good optimizer, which we > won't have for a long time. I want a truly concurrent solution. You may want > to do a google search on "bitc-dev garbage collection" to find the previous > threads. There were a bunch of long discussions about six months ago.
thanks, yeah, i can believe i'm behind the times on all such things, and i don't know/understand enough to not just get pulled into the "now how much would you pay!" part of the abstracts :-) looking forwards to BitC! i'll be able to stop my search! assuming it as an FFI to C, and a back-end for mobile device cpu types :-) ... mainly i've been looking at gc papers wondering if i (ok not really me in reality but somebody) could modify some extant language like haxe/hxcpp or ocaml or whatever to take advantage of these developments in gcs. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
