The Artima Developer Community
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

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 81 replies on 6 pages [ « | 1 2 3 4 5 6 | » ]
Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Myths of Memory Management Posted: Sep 6, 2005 5:17 PM
Reply to this message Reply
Advertisement
Oops! The sentence "but that destructor will only be called if the GC decides it needs more memory -- an event completely unrelated to memory management." should read "but that destructor will only be called if the GC decides it needs more memory -- an event completely unrelated to whether the lock is needed. In the meantime all other objects wanting that lock just have to wait."

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: Myths of Memory Management Posted: Sep 6, 2005 6:11 PM
Reply to this message Reply
> The cost of GC in Java is that every other resource must
> be manually handled.

You could argue that you have to handle resources manually in C++ even when you are using RAII: You have to manually specify that you are using a RAII handle.

For resources that can be acquired and released in a stack-like fashion, you can use higher-order programming to avoid having to separately call a function to release a resource. If you are an Emacs guy, then type M-x describe-function with- [TAB] and choose any of the functions to see a concrete example of what I mean. In Java, you can use anonymous inner classes (although the syntax is somewhat verbose).

Jan H. Hansen

Posts: 1
Nickname: jhhdk
Registered: Sep, 2005

Re: Myths of Memory Management Posted: Sep 7, 2005 7:24 AM
Reply to this message Reply
Dejavu of beating a dead horse.
Granted
A a = new A();
a = null;

not much different from:
A a = new A();
delete[] a;

But
A a = new A(new B(), new C());
a=null;


Very different from:
A a = new A(new B(), new C());
delete[] a;
~A(){
delete[] b;
delete[] c;
}

GC detects disconnected graphs of objects whether they contain cycles or not and reclaim them. Languages with explicit deallocation typically don't.
To be fair people may not give deallocation of ressources external to JVM enough considderation, but GC still cause HUGE improvements to productivity when only working with "java native"-ressources like memory.
I can understand that C++ guru's who are experts in tracking down memory leaks or writing code that doesnt leak to begin with feel frustrated that their skills are becoming obsolete, but starting discussions about a topic that's been debated to death years ago doesn't solve anything.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Myths of Memory Management Posted: Sep 7, 2005 7:46 AM
Reply to this message Reply
  A a = new A(new B(), new C());
  delete[] a;
  ~A(){
    delete[] b;
    delete[] c;
  }


First that is C++, secondly it is naively written C++. In Heron that would be written as:

class A {
  public {
    _init(B^ ab, C^ ac) {
      b = transfer(ab);
      c = transfer(ac);
    }
  }
  fields {
    scoped<B> b;
    scoped<C> c;
  }  
}
 
...
scoped<A> a = new A(new B(), new C());
 


There is no need for a destructor, or an explicit call to delete.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Myths of Memory Management Posted: Sep 7, 2005 8:41 AM
Reply to this message Reply
> And, no, finally blocks don't solve anything here. Why?
> Because you can't say "delete X" in a finally block. You
> u 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.

And why is it better to manually delete the Objects than to manually release call a 'release' method?

BTW, finalizers are generally not recommended in Java anymore. It's better to use PhantomRefences for this type of work.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Myths of Memory Management Posted: Sep 7, 2005 8:49 AM
Reply to this message Reply
> Given that a programmer in Java or C# should be setting
> their pointers to NULL, what is the difference between
> that and explcitly calling a delete? The answer is more or
> less nothing.

Yes, and setting Objects to null is mostly unecessary.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Myths of Memory Management Posted: Sep 7, 2005 9:20 AM
Reply to this message Reply
I don't think there's much that can be done to roll the industry back to manual memory management (thank goodness!).

Every once in a while, I get to feeling kind of like (I guess) Chris does, that the problem isn't that programming is too hard, it's that it is too easy. I think there's something to that, when it comes to skills development, but once good coding skills are developed, it's pure overhead.

Christopher Diggins

Posts: 1215
Nickname: cdiggins
Registered: Feb, 2004

Re: Myths of Memory Management Posted: Sep 7, 2005 10:03 AM
Reply to this message Reply
> I don't think there's much that can be done to roll the
> industry back to manual memory management (thank
> goodness!).

What the heck are you talking about? There are over 30 programs currently running on my computer. I am pretty darn sure every single one of them use manual memory management. If the industry isn't using manual memory management, someone forgot to tell the people who are actually writing the software.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Myths of Memory Management Posted: Sep 7, 2005 10:21 AM
Reply to this message Reply
As I said, I'm not all that crazy about some of the acrobatics "exception safe C++" requires. I've largely ignored Java for the last few years because, until very recently, it was a language where easy things were easy, but nothing else was possible. Now some interesting research is going in that direction, so it's useful to learn some of the more recent idioms.

And, for the record, I keep trying to learn ML, but I keep running into math-only examples and I don't usually have math-only problems. I'm sure ML is useful in other domains, but that's been my hangup so far.

Now, on to the C++ view. I'm not a fan of those people who write:

void foo()
{ hotdog A = new hotdog(5);
// ... lots of stuff
delete A;
}

But I'm fine with:

void foo()
{ hotdog A(5);
// ... same stuff
};

And I'm fine with:

class lock_file
{ lock_file(std::fstream fs)
{ // lock fs
}

~lock_file()
{ // unlock fs
}
}

Which is then used:

void change_file(std::fstream file)
{ lock_file lck(file);
// do whatever w/ file
};

That is, as an automatic variable, ~lock_file will be called at the end of its scope -- I don't have to remember, AND I know WHEN it will happen. (Yes, I know many readers know this, but a few comments convinced me that many do not).

Of course, there's no reason to believe that C++ idioms will work in Java. OTOH, BECAUSE of GC, Java programmers must handle all other cleanup by hand (http://www.codeguru.com/java/tij/tij0051.shtml).

My reference to "finally" was actually not a reference to finalizers, but a reference to the strange attempt Java's designers made at making exception safe code (try ... catch ... finally). The concept is that the GC will take care of the memory leaks, but the finally block must be there to take care of any other necessary cleanup.

Is this a damning indictment of GC? Not at all. It's a question about the sanity of Java's implementors.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Myths of Memory Management Posted: Sep 7, 2005 10:31 AM
Reply to this message Reply
> > I don't think there's much that can be done to roll the
> > industry back to manual memory management (thank
> > goodness!).
>
> What the heck are you talking about? There are over 30
> programs currently running on my computer. I am pretty
> darn sure every single one of them use manual memory
> management. If the industry isn't using manual memory
> management, someone forgot to tell the people who are
> actually writing the software.

I think that's the weight of history, but it's changing. Many companies I visit (not all) have or are in the process of moving away from C/C++ to Java or .NET. I'm searching my memory for case where a team has migrated in the other direction.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Myths of Memory Management Posted: Sep 7, 2005 10:45 AM
Reply to this message Reply
> Sure GC is not neccessarily slower, nor is it neccessarily
> faster. It depends on what GC mechanism you use, and what
> hard-coded technique you compare it to. Every case is
> unique. However theoretically any generalized
> automated GC can be optimized by hand for any given
> particular non-trivial software. In practice it is rarely
> practical to do so.

Still, I read things like this and I have to wonder whether most discussions of performance are just out of habit:

http://www.dadgum.com/james/performance.html

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Phantom References? Posted: Sep 7, 2005 10:53 AM
Reply to this message Reply
Can somebody direct me to a Phantom References link? All I can find is at http://forum.java.sun.com/thread.jspa?threadID=609458&messageID=3357928 which includes this gem "The running app closes the stream, and nullifies the object's reference just to be safe.

Unfortunately, the JVM has other plans in mind. It throws the old Stream object into the garbage collector's work heap, then forgets it ever existed without bothering to stick around and personally make sure the file lock is released RIGHT AWAY" (third message).

yuckie

Posts: 1
Nickname: yuckie
Registered: Sep, 2005

Re: Myths of Memory Management Posted: Sep 7, 2005 10:55 AM
Reply to this message Reply
You are simply out of your mind.

If you think you can manage memory better than the GC then go ahead and do it, theres plenty of languages out there you can do it in. Have fun!

Memory management is not mythical nor is it as simple as saying 'just call delete or just null stuff out'.

To suggest otherwise is a bunch of hooey and I cant believe this article got posted on the server side.

Max Lybbert

Posts: 314
Nickname: mlybbert
Registered: Apr, 2005

Re: Myths of Memory Management Posted: Sep 7, 2005 10:59 AM
Reply to this message Reply
Oops. Read the rest of that last article and found, "Among other things, I went overboard trying to be clever using chains of anonymous objects in constructors, and was fairly promiscuous about spewing references to the constructed objects all over the place for no apparent reason. Ultimately, the FileInputStreams couldn't be explicitly closed because I had no direct reference to them, and ultimately depended upon having the garbage collector realize it had fallen out of scope and could be safely closed as well after the GZIPInputStream created from it was closed. Throw in a sleep-deprived 5am stupid decision to use the GZIPInputStream objects as Map keys for no (in retrospect) sane, apparent, or useful reason, and it's probably nothing short of blind luck that I was able to make it work at all."

So Java programmers felt this was his fault, and I can see why. OTOH, if GC makes life easy, what would you call this?

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

GC -> Non-GC transitions Posted: Sep 7, 2005 11:04 AM
Reply to this message Reply
> I think that's the weight of history, but it's changing.

Indeed.

> Many companies I visit (not all) have or are in the
> e process of moving away from C/C++ to Java or .NET. I'm
> searching my memory for case where a team has migrated in
> the other direction.

The only common case I see for that these days is Mac OS X development where, despite Apple's marketing to the contrary, Java is very much a second-class citizen compared to Obj-C.

Also, of the fresh C/C++ development that I've seen in complex applications, more are using GC solutions.

Flat View: This topic has 81 replies on 6 pages [ « | 1  2  3  4  5  6 | » ]
Topic: How Much Profit is Enough? Previous Topic   Next Topic Topic: QA and TDD


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us