| |||||||||||||
PausesPausesPosted Jul 8, 2010 14:36 UTC (Thu) by etienne (subscriber, #25256)In reply to: Pauses by nix Parent article: The Managed Runtime Initiative
> Note that reuse of tree nodes is a classic example of a time where GC is
> very useful, because all of a sudden that object's lifetime must be > extended, and telling the entity that originally allocated it is likely > to be unpleasant.
I am not a specialist of GC, but I wonder if the usual malloc/free interface is wrong, and if we should use something like malloc/memlock/free.
(Log in to post comments)
Pauses Posted Jul 8, 2010 14:52 UTC (Thu) by nye (guest, #51576) [Link]
>Basically, the function which create the data allocates it, all functions using the data memlock() it, and every function calls free() when it finishes using that data. Free() decrements a counter and frees the memory when the counter reaches zero.
How would this be different from any other form of reference counting, with its attendant problems?
Pauses Posted Jul 9, 2010 16:22 UTC (Fri) by nix (subscriber, #2304) [Link]
Straight reference counting works if you can tell who the 'users' are, and if the data structures are fairly simple. But we can't really ask everyone touching a graph to walk the entire graph and all its data structures and increment, then decrement, all its reference counts (that would be much more cache-unfriendly and unpleasant to maintain than what is done now); and because nodes are often shared between graphs we can't have one giant reference count across the whole graph... and if the reference-count-freer walks the graph and only frees if all connected entities are at refcount zero, you might as well drop the reference count, because what you've got there is a garbage collector. :)
|
|||||||||||||