Competing criteria

[Phil Carmody]

Never used? I can point to several places in the linux kernel where it's
done (and those are just in Nokia's contributions to the kernel, there
may be many others).

If you need a contiguous block of physical memory for DMA, for example,
then first you ask for what's ideal, and then reduce your request if
that fails. Lather, rinse, repeat, until it's futile.

It also means to write more code, some of which is almost never going to
get used... I mean, it would be like writing a program so that it runs
both on systems with an FPU and without: You basically have to write it
twice. It is almost always simpler to just say "Buy an FPU!" or "Buy
more RAM or enlarge the swap file!"

If the software vendor is also the hardware vendor, then he cannot blame
the user for the version of the hardware that he's shipped.

Phil

 

[nroberts]

True, but it doesn't prevent memory allocation from failing due to a lack
of resources.  So you still have to deal with memory allocation failures.

And given a choice between rare failures due to fragmentation, and frequent
failures due to poor choice of static limits...

This is sort of where I am.

Most high-availability systems developers don't limit themselves to
not using heap memory, right? It seems to me that in systems like
that, which are on large, fast servers with lots of memory, shouldn't
run into memory issues a lot. Or am I mistaken?

I mean, the front end for this service is a soap server. Certainly
the likes of Tomcat are using heap memory... right?

It seems to me that I should be more worried about robustness than
what appears to me an unlikely scenario in which memory fragmentation
keeps me from allocating a 100 byte string. I'd also think that
maintenance and simplicity should be a higher concern.

I understand what some are saying here, how even in hosted
environments malloc calls can fail...but how often does this really
come up? I've never seen it happen when there wasn't a deeper,
underlying issue causing a loop to run amok or some kind of
ridiculously erroneous size request. In my experience anyway, you're
more likely to run into a bug in your code causing a cascade failure
than malloc returning null.

 

[Richard Damon]

This is sort of where I am.

Most high-availability systems developers don't limit themselves to
not using heap memory, right? It seems to me that in systems like
that, which are on large, fast servers with lots of memory, shouldn't
run into memory issues a lot. Or am I mistaken?

I mean, the front end for this service is a soap server. Certainly
the likes of Tomcat are using heap memory... right?

It seems to me that I should be more worried about robustness than
what appears to me an unlikely scenario in which memory fragmentation
keeps me from allocating a 100 byte string. I'd also think that
maintenance and simplicity should be a higher concern.

I understand what some are saying here, how even in hosted
environments malloc calls can fail...but how often does this really
come up? I've never seen it happen when there wasn't a deeper,
underlying issue causing a loop to run amok or some kind of
ridiculously erroneous size request. In my experience anyway, you're
more likely to run into a bug in your code causing a cascade failure
than malloc returning null.

Note that this thread started on a design rule for *embedded* systems of
not using the heap. Once you get out of the embedded world, and for this
purposes I suppose the line is somewhere near having mass-storage and
virtual memory, the game changes. Here, normally long before you
actually run out of heap, other issues tend to affect your system
performance.

 

[Nick Keighley]

It also means to write more code, some of which is almost never going to
get used... I mean, it would be like writing a program so that it runs
both on systems with an FPU and without: You basically have to write it
twice. It is almost always simpler to just say "Buy an FPU!" [...]

At the times this was likely to occur there were usually multiple
versions of the math library. The application was not aware if the FPU
was present or being emulated (apart from a slight loss of
performance...)

<snip>