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... Rifat Shahriya et al rejected it despite small heaps , low allocation/deallocation pauses and high performance ( 2% better than best MMTk - though 2003 version) because of complexity of copying but to me subjectively its less complex than RC-Immix (maybe because its a Nursery and RC which we have a good handle on) . Like RC-immix pinned interop objects can avoid the copying Nursery (as well as large). Newer ref counting techniques may avoid the write barrier cost a lot ( as its copying nursery you need it for old to new) .. The Nursery starts at the heap size which is great for stupid micro benches ... many will have 0 memory cost with linear allocationand no deallocation cost but not so good for quick release of resources held (though IDisposable can take care of that ). This scheme is very attractive if you want shorter allocation pauses its better than RC and i suspect malloc and RC-Immix due to bulk release of new objects.
I also wonder if you can reduce the write barrier frequency and just switch nurseries and do a full trace on a background thread ( increasing speed and memory but increasing worst case pause) Alternatively a card table barrier may work better ( but they only need the write barrier on Old to Nursery , so its a bit diffirent) . This tracer can also remove cycles later but i dont think its high priority since a large configurable Nursery ( which it has ) will remove the cycles that cause the most problems. Long running cycles are either program life time or easy for a programmer to manually remove , via holding a manual reference. Lastly this works better if you wish to have a GC as well which you mentioned ( though im not sure why). 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. BTW anyone seeen a paper employing all the latest Ref counting techniques to a C++ like system ( or better yet a JIT ) without an object header ( so no runtime getType() on non virt objects ) ? This is why im advocating going with simple ref counting with some advanced techniques , tune it and then evolve it. There is obvious potential in these techniques but which one is best is very hard to determine without a more complete BitC with some test benches and even then its expensive to trial more complicated systems so do the simplest ones first. Anyway the key point is ref counting will do the job well. Ben http://www.cs.utexas.edu/users/mckinley/papers/urc-oopsla-2003.pdf http://www.powershow.com/view/14655a-<http://www.powershow.com/view/14655a-MGM5M/Ulterior_Reference_Counting_Fast_Garbage_Collection_without_a_Long_Wait_powerpoint_ppt_presentation> MGM5M/Ulterior_Reference_Counting_Fast_Garbage_Collection_without_a_Long_Wait_powerpoint_ppt_presentation<http://www.powershow.com/view/14655a-MGM5M/Ulterior_Reference_Counting_Fast_Garbage_Collection_without_a_Long_Wait_powerpoint_ppt_presentation> )
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
