Weblogs Forum - Myths of Memory Management

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Myths of Memory Management

81 replies on 6 pages. Most recent reply: Sep 12, 2005 3:10 PM by Max Lybbert

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 81 replies on 6 pages [ « | 1 2 3 4 5 6 | » ]

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Memory management vs. Resource management

Posted: Sep 6, 2005 12:13 PM

> > See Anjan Bacchu's post:
> >
> > There is one case where the use of explicit nulling
> is
> > not only helpful, but virtually required, and that is
> > where a reference to an object is scoped more broadly
> than
> > it is used or considered valid by the program's
> > specification.
>
> Yes, that's a design bug, not a problem with GC-based (or
> manual) memory management.

My point was to counter your statement: "For example, there's no need to set references to null in e.g., Java.". This is precisely the point of my blog, a GC lulls you into thinking you can ignore memory management, though in reality it just leads to subtle design flaws which slip by unnoticed.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Memory management vs. Resource management

Posted: Sep 6, 2005 12:30 PM

> > Yes, that's a design bug, not a problem with GC-based (or
> > manual) memory management.
>
> My point was to counter your statement: "For example,
> there's no need to set references to null in e.g., Java.".
> This is precisely the point of my blog, a GC lulls you
> into thinking you can ignore memory management, though in
> reality it just leads to subtle design flaws which slip by
> unnoticed.

Huh? A developer in a language with garbage collection still has to deal with memory management (and resource management). As with anything, one has to understand what's going on.

I concur that developers often don't know what's going on as well as they should but that applies at least as much to manual memory management as it does to GC-based systems.

The GC-based systems attempt to take away a lot of the cases that cause problems. As I've noted, given the current design of the general purpose languages, there's always going to be odd problems both in GC and non-GC approaches precisely because they don't really deal with the issue of general resource management in any sort of useful way.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Nulling for fun and profit

Posted: Sep 6, 2005 12:45 PM

And what are the other solutions avoiding nulling? (Assuming also that a stack implementation based on a dynamically allocating linked list would not fulfill the performance requirements.)

In general, how do you implement efficient imperative containers (and data structures in general) without ever explicitly setting references to null?

I'm not talking about resource management here. Just plain old memory management.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Nulling for fun and profit

Posted: Sep 6, 2005 12:51 PM

> In general, how do you implement efficient imperative
> containers (and data structures in general) without ever
> explicitly setting references to null?

So Vesa, we agree nulling is important. Is there any reason why a language shouldn't make nulling mandatory?

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Nulling for fun and profit

Posted: Sep 6, 2005 12:56 PM

> And what are the other solutions avoiding nulling?
> (Assuming also that a stack implementation based on a
> dynamically allocating linked list would not fulfill the
> performance requirements.)

Well, why are you implementing a stack manally instead of using one of the collection classes?

> In general, how do you implement efficient imperative
> containers (and data structures in general) without ever
> explicitly setting references to null?
>
> I'm not talking about resource management here. Just plain
> old memory management.

No, it really is the boundary between the two. A stack is a resource management tool. The implementation thereof either utilizes other resource management facilities (like the collection classes) or implements it manually.

In the manual case in those kinds of languages, I'm perfectly fine with choosing to manually null (for e.g., performance) precisely because I understand that it's a resource management problem and, in those languages, resource management is a manual problem.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Nulling for fun and profit

Posted: Sep 6, 2005 1:08 PM

> nulling is important.

Yes. I've never said it wouldn't be required in special cases. In fact, I specifically hinted that it is needed when you implement imperative containers.

> Is there any reason why a language shouldn't make nulling
> mandatory?

It is only needed in special cases. For every line of an imperative container implementation, there are at least 1000 lines of other kind of code where nulling isn't required (and usually would just reduce performance).

Also, I agree with John D. Mitchell in that failure to scope variables (or bindings) properly so as to avoid space leaks is a design/programming problem. It has very little to do with GC. The space leak would occure even with RAII.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Nulling for fun and profit

Posted: Sep 6, 2005 1:22 PM

> Well, why are you implementing a stack manally instead of
> using one of the collection classes?

Sigh. I'm sorry. Most people I have conversations with are intelligent enough to recognize that examples are exactly that: examples. They are meant to stand as a particular representative of an entire class of things that share the properties being discussed. Here is a quote from Merriam-Webster (http://www.m-w.com):


  "3 : one (as an item or incident) that is representative
   of all of a group or type"

> No, it really is the boundary between the two. A stack is
> a resource management tool.

Well, I guess you could describe it as a resource management tool. However, I don't usually consider the kinds of things that I put into a stack as resources, though. The most common use of a stack seems to be a dispenser for some elements (hardly ever "resources") being processed by an algorithm.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Nulling for fun and profit

Posted: Sep 6, 2005 1:32 PM

> > Well, why are you implementing a stack manally instead of
> > using one of the collection classes?
>
> Sigh. I'm sorry. Most people I have conversations with are
> intelligent enough to recognize that examples are exactly
> that: examples. They are meant to stand as a particular
> representative of an entire class of things that share the
> properties being discussed. Here is a quote from
> Merriam-Webster (http://www.m-w.com):

> "3 : one (as an item or incident) that is
> is representative of all of a group or type"

And that type of question is exactly the same for all of that class of questions. All too often, programmers myopically focus on some relatively narrow issue and completely miss/ignore the bigger issues that e.g., completely obviate the little issue.

Snotty, ad hominem attacks are a pretty weak way to have a useful conversation. Geez.

> > No, it really is the boundary between the two. A stack is
> > a resource management tool.
>
> Well, I guess you could describe it as a resource
> management tool. However, I don't usually consider the
> kinds of things that I put into a stack as resources,
> though. The most common use of a stack seems to be a
> dispenser for some elements (hardly ever "resources")
> being processed by an algorithm.

You might want to look up "resources". Unless you never put anything into your e.g., stack except atomic types then you are clearly using it for resource management. Even that atomic case is arguable but I'll leave that alone.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Nulling for fun and profit

Posted: Sep 6, 2005 1:55 PM

> Snotty, ad hominem attacks are a pretty weak way to have a
> useful conversation. Geez.

In an ad hominem attack one criticizes an idea by attacking the person: http://c2.com/cgi/wiki?AdHominem . If you read my comment carefully, you will see that I didn't criticize your idea on the basis of your person. IOW, not all personal comments are ad hominem. I can call you an idiot, but it doesn't make it an ad hominem, unless I'm using it as an argument to criticize your idea.

To me, your question seemed totally pointless (an intentional red-herring). It seemed absurd to me that you wouldn't genuinely understand that nulling is required to implement imperative containers in a space safe manner.

> You might want to look up "resources". Unless you never
> put anything into your e.g., stack except atomic types
> then you are clearly using it for resource management.

So, when I'm putting, say, integers into a stack, then I'm not using a stack for resource management.

> Even that atomic case is arguable but I'll leave that
> alone.

So, I guess we can agree then that a stack is not only a resource management tool.

Note that the same issue appears in other imperative data structures. I think it requires quite a stretch to say that all data structures are resource management tools and that everything put into a data structure is a resource.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Nulling for fun and profit

Posted: Sep 6, 2005 2:10 PM

> > Snotty, ad hominem attacks are a pretty weak way to have a
> > useful conversation. Geez.
>
> In an ad hominem attack one criticizes an idea by
> attacking the person: http://c2.com/cgi/wiki?AdHominem .
> If you read my comment carefully, you will see that I
> didn't criticize your idea on the basis of your person.
> IOW, not all personal comments are ad hominem. I can call
> you an idiot, but it doesn't make it an ad hominem, unless
> I'm using it as an argument to criticize your idea.

So it's okay to be snotty and make personally disparaging remarks? Bah.

> To me, your question seemed totally pointless (an
> intentional red-herring). It seemed absurd to me that you
> wouldn't genuinely understand that nulling is required to
> implement imperative containers in a space safe manner.

Thanks for proving my point.

> > You might want to look up "resources". Unless you never
> > put anything into your e.g., stack except atomic types
> > then you are clearly using it for resource management.
>
> So, when I'm putting, say, integers into a stack, then I'm
> not using a stack for resource management.

No, I said that that's arguable because they are values. Depending on your language, world-view, etc. that fact blurs the line as to what resources need to be managed. Atomic values in e.g., Java don't need any management and so it's easy to argue that they aren't resources. Of course, with facilities like auto-boxing in Java v5, that becomes yet another slippery slope.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Nulling for fun and profit

Posted: Sep 6, 2005 3:00 PM

> So it's okay to be snotty and make personally disparaging
> remarks? Bah.

Depends. I've met many snotty people who knew their stuff. I can take snotty remarks as long as they are right. It is the snotty people who don't know their stuff that annoy me.

Perhaps you don't see it that way, but to me, your question was the original disparaging remark. I interpreted it as "oh shit, I can see I'm losing this argument, but I'll throw in a red-herring to avoid having to admit that I was wrong". However, based on subsequent discussion, it seems that "doesn't this idiot know that stacks are already part of the standard library" is probably a more accurate interpretation.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Myopia

Posted: Sep 6, 2005 3:11 PM

> Perhaps you don't see it that way, but to me, your
> question was the original disparaging remark. I
> interpreted it as "oh shit, I can see I'm losing this
> argument, but I'll throw in a red-herring to avoid having
> to admit that I was wrong". However, based on subsequent
> discussion, it seems that "doesn't this idiot know that
> stacks are already part of the standard library" is
> probably a more accurate interpretation.

I suggest actually reading what's written rather than some fanciful creation.

Alas, that's exactly my point as to why that type of question is so crucially important in the software world: programmers tend to myopically focus their attention on very narrow areas and completely miss the really important information that is part of the bigger picture.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Myopia

Posted: Sep 6, 2005 3:47 PM

> I suggest actually reading what's written rather than some
> fanciful creation.

Sorry, but it isn't that simple. I recall Gerald Weinberg (it was either in The Psychology of Computer Programming or Becoming a Technical Leader) recommending a book by Virginia Satir on family therapy. The recommendation concerns the fact that communication isn't as simple as it may seem. What you have in mind gets lost when you write it down. You may even make the occasional spelling error. When I read what you wrote down, I may miss/misread a crucial word or punctuation mark. Then I'll interpet the message based on my experiences. The meaning that I finally get may be totally different that what you had in mind. It is easy to forget this. Another insightful source on the difficulty of communication would be Alistair Cockburn's book Agile Software Development.

So, I guess I should apologize. I perhaps misinterpreted the intent of your question. Sorry.

However, I still stand by my statement that nulling references is necessary in special cases to avoid space leaks, and I guess we agree on this. What we may disagree about is whether the nulling is about resource or memory management, but that's more of a play on words.

> Alas, that's exactly my point as to why that type of
> question is so crucially important in the software world:
> programmers tend to myopically focus their attention on
> very narrow areas and completely miss the really important
> information that is part of the bigger picture.

Good point.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Re: Myopia

Posted: Sep 6, 2005 4:07 PM

> > I suggest actually reading what's written rather than some
> > fanciful creation.
>
> Sorry, but it isn't that simple. I recall Gerald Weinberg
> (it was either in The Psychology of Computer Programming
> or Becoming a Technical Leader) recommending a book by
> Virginia Satir on family therapy. The recommendation
> concerns the fact that communication isn't as simple as it
> may seem. What you have in mind gets lost when you write
> it down. You may even make the occasional spelling error.
> When I read what you wrote down, I may miss/misread a
> crucial word or punctuation mark. Then I'll interpet the
> message based on my experiences. The meaning that I
> finally get may be totally different that what you had in
> mind. It is easy to forget this. Another insightful source
> on the difficulty of communication would be Alistair
> Cockburn's book Agile Software Development.

Yeah, I was only talking about the reading part, not the communicating part. Sorry for any confusion.

> So, I guess I should apologize. I perhaps misinterpreted
> the intent of your question. Sorry.

No worries. One of the things that I was taught was to not assume that what I believe someone is saying is what they actually mean to say. Given the narrowness of online communication, that seems to be a good approach.

> However, I still stand by my statement that nulling
> references is necessary in special cases to avoid space
> leaks, and I guess we agree on this. What we may disagree
> about is whether the nulling is about resource or memory
> management, but that's more of a play on words.

It's more than a play of words. It's one area where the memory management world intersects with more general resource management world. That's why it's so interesting and problematic. :-) Seriously, if you're into this issue and Java, you might want to check out stuff like the broken Java memory model and how it has been fixed and the JSR-166 (concurrency utilities) work.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Myths of Memory Management

Posted: Sep 6, 2005 5:15 PM

Well now that things are really heated up, I'll wade in with something that seems to be implicitly accepted:

Java's non-deterministic GC makes using a destructor for resource management utterly useless. Specifically, if the constructor acquires a lock, it is possible to prove a program correct by releasing that lock in the destructor (guarantee that for each call of the constructor, the destructor will be called exaclty once), but that destructor will only be called if the GC decides it needs more memory -- an event completely unrelated to memory management. Even nulling the object, or asking for a GC run are ways of saying "pretty please," but not guarantees that the GC will actually run.

And, no, finally blocks don't solve anything here. Why? Because you can't say "delete X" in a finally block. You can say "X.unlock_foo()" in a finally block but that's no better than saying it anywhere else.

So all locks, or other resources, must be released by hand. And I can't figure out what the destructor is for in this situation. The cost of GC in Java is that every other resource must be manually handled.

Don't get me wrong, I'm not crazy about the acrobatics programmers are required to go through to write exception safe code in C++ ("exception safe" means no memory leaks and then some). But I do like the deterministic guarantee of automatic objects. In C++ you only have to manually call delete if you called new. It makes more sense to me to use local automatic objects to take care of most memory management than to give up on MM and take over the task of resource management.

Flat View: This topic has 81 replies on 6 pages [ « | 1 2 3 4 5 6 | » ]

Previous Topic

Next Topic