On Tue, Oct 15, 2013 at 1:09 PM, Jonathan S. Shapiro <[email protected]>wrote:
> 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. > Yes thats the key .. you can say this problem is solved with potential improvements and get the rest out. > > >> 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. > Agree . His 10% ref counting is a lot simpler though he want comparing to RC-immix .. but yes i think things have changed in the last 8 years as we want more from our GCs complexity has risen. > > > > >> 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. > Yes pointers with some of them would be fun ... But you could have a safe langauge with no object header ( and value types) ..which would have a very diffirent profile .. So it looks like we can get a better safe management system than GCs but we are on our own in terms of research and what works best and can only take a guide line from them . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
