Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?
 
PerlMonks  

Re^3: How I want my memory managed

by Aristotle (Chancellor)
on Dec 14, 2002 at 23:02 UTC ( #219900=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: How I want my memory managed
in thread How I want my memory managed

You prefer a garbage collector over reference counting..?

Makeshifts last the longest.


Comment on Re^3: How I want my memory managed
Re: Re^3: How I want my memory managed
by MarkM (Curate) on Dec 15, 2002 at 02:32 UTC

    I prefer systems that do not require regular explicit house cleaning in every piece of code that accesses shared data structures. Garbage collection is one means of reducing the explicit house cleaning. Count how many times SvREFCNT_inc() and SvREFCNT_dec() appear in the Perl source code, and figure on the possibility that any of these might be invoked at the wrong time, or not enough times. At this point, I am not even considering performance, or storage. The basic principle is that a less complicated system will probably have less potential to include bugs.

    For other examples of the potential for bugs in schemes that rely on explicit house cleaning, such as reference counting, consider the delivery of signals, or the trapping of exceptions. Perl implements an interesting work-around to this problem called 'mortal scalars'. The caller maintains a set of scalars that need to be dereferenced during an unwind operation. Most code, however, creates the scalar first, and then marks it 'mortal' leaving a small window for memory to be leaked.

    Issues such as performance are a little less black and white. Anybody can write an inefficient reference counting scheme, or an inefficient garbage collection scheme. For example, earlier versions of Perl used to use a MUTEX lock around all SvREFCNT_inc() and SvREFCNT_dec() operations in the 'thread-safe' version of the code. This is horribly expensive. It is a lot more efficient to implement reference counting using native assembly code, at least for common platforms, as operations like SvREFCNT_dec() can usually be implemented to be as cheap as a standard decrement instruction followed by a test instruction, without the need for thread synchronization.

    Reference counting has benefits. As a preference, though, I could live without these benefits, if it improved my level of comfort in the code base.

      I know all that. :) My point is that reference counting is a technique of garbage collection.. so you got your terminology mixed up. What you meant to say is mark&sweep vs refcounting.

      Makeshifts last the longest.

        Ah yes... terminology... sorry... :-) Replace every occurrence of 'garbage collection' with 'non-reference counted garbage collection' in posts that I made. The reason I made it more vague, is because there are more ways to perform non-reference counted garbage collection than 'mark & sweep'. The most obvious example is a 'copy' garbage collector.

        Technically, you are definately correct that reference counting is a form of garbage collection.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://219900]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (11)
As of 2014-10-23 08:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    For retirement, I am banking on:










    Results (125 votes), past polls