Why free memory on application quit?

Member
Posts: 72
Joined: 2006.10
Post: #16
OSC: The situation in question came up because due to a design change by the client, we had to temporarily instantiate a good chunck of a game a second time. Now, great parts of this was doing a mish-mash of proper cleaning or not, or even double-deleting at times. It didn't use to matter because the game would just quit. But try to instantiate and eventually delete a second one and all hell breaks loose. Had the game done proper cleaning, this would never had been an issue.

FreakSoftware Wrote:sohta: Did you know that that every Mac OS X Cocoa application out there does not free all of its memory before it quits? After a certain point in the termination process is reached, the whole process just exits rather than release every single object first.

I am well aware of this.I would never dream shipping a game that does proper cleaning up. However, it still does it during most of the development cycle.

- Sohta
Quote this message in a reply
Member
Posts: 81
Joined: 2007.05
Post: #17
Just curious, is OS X going to automatically deallocate fbos, textures etc. in vram on a video card if the application just quit? I suppose if the application exits and the context gets destroyed it would somehow trigger the video card to clean up? Would it depend on the driver implementation and could this be different on other platforms?

I try to deallocate memory. But having the OS do it for me on exit is nice.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #18
sohta: So now you're doing more unnecessary work up-front because you were bitten once by an impossible request from a client? That's not a good way to build software. It's called Speculative Generality, and it is widely regarded as a Very Bad Ideaâ„¢.

macnib: If there is any trace of your process left, anywhere, after it exits, that's an OS bug (certain bizarre POSIX semantics aside, perhaps).

To add to what Seth said: no application written in any garbage-collected language (Ruby, Python, Java, ObjC-GC, Haskell, Scheme, etc.) ever cleans up before quitting.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #19
OneSadCookie Wrote:It's called Speculative Generality, and it is widely regarded as a Very Bad Ideaâ„¢.

Speculative Generality sounds like the very basis of C++ Rasp

In all seriousness though, fighting back against Speculative Generality can be tough sometimes. Cutting things down to a bare-bones "less is more" approach can pay off big though. The fewer the features, the fewer opportunities there are for bugs. The fewer lines of code to look at, the easier it is to find mistakes. I know those seem like total "duh!" statements, but I've seen so much crappy, bloated code out there that apparently many developers don't think like that when they're coding [I'm often guilty of code bloat too].
Quote this message in a reply
Member
Posts: 749
Joined: 2003.01
Post: #20
Quote:Speculative Generality sounds like the very basis of C++
Meh, C++ just gives you more power, if you abuse it it's your fault not C++'s.

Edit: Hmmm, I figured some people might hate it when they have to figure out other people's "abusive" C++ code... and that's why they hate the language itself!

©h€ck øut µy stuƒƒ åt ragdollsoft.com
New game in development Rubber Ninjas - Mac Games Downloads
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #21
I don't hate the language, but it's hard not to take a jab at it once in a while, when the opportunity presents itself. Wink

The anal-retentive memory management thing certainly isn't exclusive to C++, although I do generally tend to speculate that C++ fans are often the biggest speculative generalists. [yes that was another cheap jab for the fun of it, maybe not remotely accurate, but fun for me all the same!]
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #22
OneSadCookie Wrote:To add to what Seth said: no application written in any garbage-collected language (Ruby, Python, Java, ObjC-GC, Haskell, Scheme, etc.) ever cleans up before quitting.

Dunno about the others, but it's not true of Ruby for sure.

Code:
lulu:~ slembcke$ irb
>> ObjectSpace.define_finalizer(Object.new){puts 'final'}
=> [0, #<Proc:0x0036847c@(irb):1>]
>> ^Dfinal

It's not just finalizers either. If you put logging statements in your garbage collection C functions, it will call those too. I assume this is because, although highly discouraged, finalizers and destructors can be used to do more than free resources.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #23
Skorche Wrote:I assume this is because, although highly discouraged, finalizers and destructors can be used to do more than free resources.

That's weird. Like what else besides freeing resources would be appropriate in a destructor?
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #24
Skorche: interesting; I can kinda see the logic in running finalizers, but collecting everything seems overkill...
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #25
AnotherJake Wrote:That's weird. Like what else besides freeing resources would be appropriate in a destructor?

IO objects are a good example. They close the stream when they are collected. You don't want them to just leave it open because it may be a long time before the program exits.

Now consider that you've built some buffered IO object on top of that. If it was simply allowed to be GCed, it may still have data buffered that hasn't been written to the physical stream. If the stream was to be closed before the buffered data is written to it, it would corrupt the data.

OneSadCookie: Again, I assume it has to do with it being impossible to tell which destructor functions are safe to skip, and which ones aren't.

Back to the original topic. I once thought that it was good practice to free everything before the program quit, but have since come to agree with the consensus here. It doesn't actually benefit anybody, so why bother?

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Oldtimer
Posts: 834
Joined: 2002.09
Post: #26
Right, I can see the technical reasons being sound here, but I would feel so dirty! I'm cleaning everything else up everywhere else, and it would seem a terrible oversight not to be thorough with it. :/

I would make a bathroom metaphor if it wouldn't ruin your lunch.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #27
Cleaning up resources, such as sockets, is a good idea, but RAM is just reclaimed by the OS anyway. I think the anti-pattern here is that people rely on destructors to free up resources when quitting an application.
Quote this message in a reply
Moderator
Posts: 3,579
Joined: 2003.06
Post: #28
Skorche Wrote:IO objects are a good example. They close the stream when they are collected. You don't want them to just leave it open because it may be a long time before the program exits.

Now consider that you've built some buffered IO object on top of that. If it was simply allowed to be GCed, it may still have data buffered that hasn't been written to the physical stream. If the stream was to be closed before the buffered data is written to it, it would corrupt the data.

That's a pretty good example. I was thinking that an IO buffer should be strictly handled by the runtime environment when things shut down, but there doesn't seem to be anything inherently wrong with letting objects finish up to prevent data corruption.
Quote this message in a reply
Member
Posts: 26
Joined: 2008.08
Post: #29
If I understand correctly, Google Chrome (chromium) treats each tab, window, and plug-in as its own, separate process, singularly so as to avoid garbage collection altogether -- instead, it kills tabs upon loading, reloading, and closing tabs. You'd need a copy of Windows to see it in action, however, as I understand that the 'Chrome developers have yet to release ports to any other system.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #30
aardvarc Wrote:singularly so as to avoid garbage collection altogether

It's also for stability. If one tab process crashes, it doesn't have to bring down the entire application.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  My game crashes on quit... hangt5 17 8,447 Jan 30, 2005 09:38 PM
Last Post: hangt5
  Carbon Apple quit Event troubles deekpyro 3 5,951 May 7, 2002 06:24 AM
Last Post: deekpyro