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. > "My main interest in reference counting is the ability to bound the space/delay tradeoff on dead objects turning into re-allocatable space" URC as well , its only the nursery that has non minimal time for this ( as any deffered new obj scheme will have) . Their default is to have the whole heap as Nursery and then reduce size as objects are moved . While this trade off is not explored in the paper they do say its configurable ( obvious anyway) so you can set a very small Nursery and have basically standard reference counting with immediate release ( or even disable the Nursery). There is also a timer on the Nursery which can be adjusted more collections however will result in higher CPU so you get a CPU /delay tradeof. I think the Nursery will make fragmentation less of an issue as per the comments posted earlier on Gen Immix being better on small heaps. Why is this trade of important ? I dont see it an issue with most GCs? I can understand system resources but memory i dont unless its due to fragmentation in some systems but requiring more memory does the same.. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
