|
What exactly would you do in a situation where you just ran out of memory? Doing pretty much anything at all is going to require allocating memory. Memory that is probably unavailable. In C++, if you do anything, you could override the default 'new' allocator and display a message box or something and then bail. But if you just ran the system out of memory, there isn't a whole lot of chance that the message box is even going to appear in the first place. An unhandled exception from a RAM allocation failure, on the other hand, that gets to the top and terminates the application allows the application to be debugged later by leveraging WER. This allows the author to focus on getting code written and not writing a zillion different little "what-if" lines of code. Additionally, a lot of authors simply assume low memory scenarios will get handed off to swap, which generally works - sluggishly, but it works. Granted, this perhaps isn't the way to handle low memory scenarios, but I can't remember the last time Windows said, "This program crashed because it couldn't allocate the necessary memory." Nor have I ever seen Windows offer to tell the user that if they kill programs X, Y, and Z off, the program they are running will have more memory and run faster.
|
|
|
|
|
I remember back in my C++ days it was a trick to allocate a big chunk of "emergency buffer" memory that could then be freed and used in such situations, but that was really low-level stuff. Can it even be done in a managed environment? (I mean you can't even explicitly "free" memory anymore.)
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Check out my blog! )
|)””’) piHole.org
-”-”-
|
|
|
|
|
I am always shocked when I don't see any testing for this; just crashing is unacceptable behavior.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
When I wrote in C++, every allocation was followed by a check for null-ness. In .Net I don't perceive the necessity for everyday code. I suppose that if you're loading a crap-load of data, you should be concerned, but I haven't been in that situation yet.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Anyone working on that kind of stuff would (should) undoubtedly care about memory but I suspect few of us are working on those things when we can just by a component to handle it for us. There's little profit in re-inventing wheels after all.
"It's so simple to be wise. Just think of something stupid to say and then don't say it."
-Sam Levenson
|
|
|
|
|
I thought about it a few years ago. In fact for most lines of our codes we can add at least a line to verify if it worked correctly or not. These verifications may multiply the size of the code but probably produces a great product that does not behave randomly or throwing strange unfriendly messages to the user. A professional job. The problem is the cost and time.
Programming is a slow and time consuming job. Making a perfect application is almost impossible in terms of the time and money there needs to be spent. This, probably, is the reason that we mostly focus on main functionalities of a project and ignore many other things, not that they're not important.
For some specific applications, as you stated, managing memory is a main concern influencing overall functionality of the final software, for many others it is not. That many others may state the minimum requirements for running the application and that's all many of us can afford.
Just my two cents.
"In the end it's a little boy expressing himself." Yanni
|
|
|
|
|
You're generally going home in a body bag anyway once you've run out of memory. Sure you can check, but unless you can find a way of freeing some up without your application suffering it's game over.
Regards,
Rob Philpott.
|
|
|
|
|
I agree that it's basically useless, and a well-designed program isn't likely to be able to free up its own memory at such a time anyway. That is, there shouldn't be anything unimportant just lying around that can be freed that hasn't already been.
So unless you want to start tossing the user's information, about all you can do is warn them that you're running low, and tell them they better start closing tabs (or something).
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Check out my blog! )
|)””’) piHole.org
-”-”-
|
|
|
|
|
Really depends what I'm programming in. In C++, I'd typically check all the time. In higher-level languages, C#, Java, etc. I'd rely more on the runtime to catch such conditions.
|
|
|
|
|
Also depends on platform, on desktop i also use more catches, 'cause there is enough memory, but for ex. windows mobile you don't have so much resources to spare (on older phones mostly) and there is really much bigger chance to run out of memory.
|
|
|
|
|
Sometimes out of memory errors come as side-effects also. Examples are:
1) System.StackOverFlowException (because of infinite recursion)
2) Always True Condition in a while (true) block
3) Image API when loaded with a non-image also throws this exception. The third exception, I feel, however, is a misnomer. I have written a note on this point over here sometime back: http://www.dotnetspider.com/resources/3020-Quick-Effective-Tips-Image-API-Input-Validat.aspx[^]
Please share if you have similar observations.
P.S.: The examples I have given might be based on Managed Code (C#/.NET Framework 2.0)
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
All the world's a stage,
And all the men and women merely players.
They have their exits and their entrances;
And one man in his time plays many parts... --William Shakespeare
|
|
|
|
|
When I am doing 3D medical imaging applications (where a case can be over 2GB) that must not crash for any reason, the application must handle low memory conditions before the entire address space is exhausted. For me this is usually the application deciding on what needs to be in memory now and what can be reloaded at future time. In one application I made heavy usage of memory mapped files (that can be unmapped and remapped) to solve an address space problem. If I could use a 64 bit operating system (medical display driver only 32 bit) I would not have had to manage the address space so closely though.
John
modified on Monday, September 29, 2008 2:20 PM
|
|
|
|
|
Sure, you've detected the condition, now what? You usually can't report it in any way to the user, and even if you could, what are they going to do about it anyway?
In today's age of 2+GB virtual address spaces, and page files that can conveniently be >2GB, running out of virtual memory is nearly always an indication of a more fundamental problem -- a memory leak. Since you're already leaking memory until you leak it all, by definition, you have no hope. The best you could possibly do is to report to the user "I'm broke. Please get the developers to fix me". A crash says exactly the same thing to the users and is easier to code
Of course, if the user asked you to do that, then you'd probably be better off checking to see if they have enough memory before trying instead of letting the allocation fail as your way to find out. And that's not really the spirit of the question.
patbob
|
|
|
|
|
patbob wrote: A crash says exactly the same thing to the users and is easier to code
Grim
MCDBA, MCSD, MCP+SB
SELECT * FROM users WHERE clue IS NOT NULL
(0 row(s) affected)
|
|
|
|
|
i.e. when I don't want an InsufficientMemoryException or IndexOutOfRangeException to bubble up to the end user or caller of my code.
In virtually all cases, I do want the exception to make it to the top, although for GUI apps I wrap the exception in a user-friendly application exception.
/ravi
|
|
|
|
|
It is rather unlikely that one could consume all the memory in a modern PC with anything but a gross programming error* (or a user who's too cheap to upgrade their 128 Kb system).
HOWEVER:
One should check for memory leaks - if not for protection of the system's integrity (including silly stuff like other applications that may be running and want some memory know and then), then for old time's sake.
(VB Programmers need not apply)
* E.g.: MicroSoft Windows Vista
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
You as programmer should well know, that Vista have far more sophisticated memory management routines then any other version of Windows, except Server 2008. So, this overexcited notes about how "Vista sucks in any way possible" is really annoying for everyone who have straight hands and a little real experience of using it. The one and only concern, that really apply to it, is the memory requirements of Vista, but, really, it's a little bit overrated. And anyway, don't like the product, don't use it. Want better? Make it!
|
|
|
|
|
13xforever wrote: annoying for everyone who have straight hands
Just my luck . . . nasty arthritis has left my index fingers both bent at ca. 20 degree angles and damaged some of the others, as well. No wonder Vista doesn't seem to do it for me. Hopefully, the next version of windows will have some help/enhancements for those of us who are finger-pointing-impaired.
.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
"It is rather unlikely that one could consume all the memory in a modern PC with anything but a gross programming error"
Memory doesn't just fail to allocate when virtual memory runs out, ask for enough memory in one chunk and you won't get it. Recently I had to deal with a situation where some<complete as="" desired=""> was trying to load a 200e6 sample waveform into an arbitrary waveform generator (50MHz - 1Hz signal at 200MHz) ARB's API needed a pointer to that number of doubles (i.e. ~1.5G) even with 3G memory couldn't get that in a contiguous chunk.
|
|
|
|
|
And, to add more to your answer - other responses from the (more common?) game programmers pointed out the need of a lot of video ram - a venue to which I've never ventured. I'll omit questionably relevant ancecdotes.
I do have one question: if you require such a large block of contigious memory - do you find yourself in trouble often with that application? Once upon a time, in my Fortran/Scientific programming days, when one allocated a data array, it was allocated in the executable image (not dynamically at run-time). Wasteful, for sure, but if the memory wasn't there, the application wouldn't load.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
That frequency selection was not the typical use. 1kHz resolution or higher is more usual(i.e. 1.5M or less), so allocating half my memory for a situation that occurs less than 1% of the time seemed like a bad choice. Have been trying to get "system" (read hardware) engineers to involve software engineers looking at APIs as part of the off the shelf device selection. Since the device has the memory to load such a wave it would be nice if the API had allowed me to feed it samples rather than having two copies of the data (one in the ARB, one for the API)
|
|
|
|
|
The majority of my applications aren't likely to accumulate sufficient memory to trigger an allocation failure. They don't construct large data structures or require large temporary objects.
That said, I do have one that could. It's a TCP/IP logging facility that can buffer log data over long periods. Therefore, it is designed to predict and prevent allocation failures.
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: Only when necessary
Exactly. Or at least "Only when appropriate".
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: Or
Shouldn't it be AND ?
Vasudevan Deepak Kumar
Personal Homepage Tech Gossips
All the world's a stage,
And all the men and women merely players.
They have their exits and their entrances;
And one man in his time plays many parts... --William Shakespeare
|
|
|
|
|
No, that would be incorrect grammar.
/ravi
|
|
|
|