On Mon, Oct 14, 2013 at 9:34 PM, Bennie Kloosteman <[email protected]>wrote:
> I also think Blackburn and Mckinley ulterior ref counting is worth > mentioning , they observer observing that the majority of pointer > mutations occur in young objects so use a Nursery and there system can > be improved upon as it does use the research from the last 10 years... > URC is probably worth a look. RC-immix doesn't refcount in the nursery either. I'll look quickly at URC, but I'm not so interested in looking further. My main interest in reference counting is the ability to bound the space/delay tradeoff on dead objects turning into re-allocatable space. RC-immix does that. URC may as well. Now that one (or possibly two) RC schemes are known that perform well, others will crawl out of the woodwork over time. > Rifat Shahriya et al rejected it despite small heaps , low > allocation/deallocation pauses and high performance ... because of > complexity of copying > Which is silly. The complexity isn't in the copying. It's in the need for precise root maps, and RC-immix incurs that as well. One of the changes I would make to RC-immix is to do a mark-compact in new space to support a more incremental tenuring strategy. > Lastly this works better if you wish to have a GC as well which you > mentioned ( though im not sure why). > Two reasons: 1. You still need a background GC for cycles, so you need to be able to run GC. 2. Even if RC-immix or URC is "the answer", we still want a language that can run on other runtimes that may use GC. It's not that I *want* a GC. It's that I don't want to commit myself to semantic dependencies that would *preclude* a traditional GC. > Anyway id be wary of some of these papers ( including Ulterior ref > counting) not because they are not good research they are and have nice > ideas but all of them (and a lot of the sources i checked) are all on > Jikes /JVM and say more about reference counting on Java then in general - > the figures and some issues do not agree with C++ ref counting where a > basic interlock inc operation with nothing else has a cost of ~13% > (compared to malloc not MMtk) . If you add some modern techniques and > regions analysis im sure it would be much better maybe even sub 3-4% > compared to malloc , super simple and can be improved. > C++ is a very pessimistic language for this, because it isn't memory safe. A *lot* of the optimizations in modern GC/RC schemes rely on memory safety. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
