Andrew Lentvorski wrote:
Mike Marion wrote:
Don't get me started on their incredibly stupid ass code that can be
broken by future kernel changes to values in /proc/meminfo, doing
things like causing variable overflow that makes a program malloc()
anywhere from 400meg to 980gig! at startup. This was due to a feature
they deliberately did to attempt to malloc all the ram the app thought
it might need at startup... because "it's faster that way."
As much as I hate EDA companies, I'm going to defend them on this even
though they got the explanation (sorta) wrong.
The issue is not that it is faster for the application.
The issue is that the Linux kernel *lies*.
If you ask the Linux kernel for memory, it immediately returns "Here ya
go, boss." *but doesn't allocate the [EMAIL PROTECTED] memory* until you touch it.
Because, well, that's faster.
So, you allocate a nice set of pages you think is plenty big enough to
hold your very long, very complicated computation that's going to use
all that memory and halfway through *BOOM*--out of memory. So, your
choices are to touch *every single byte* up front in order to make Linux
actually give you the blasted memory (stupid when I'm actually going to
touch the memory when I use it anyhow), or bash some undocumented things
to make sure that the kernel can and will give you the memory when you
get there.
Good programming practice (and good security practice) dictates that
when a variable is instantiated, it is initialized to some value. This
includes large blocks of memory that might hold some big blob (to use a
DB term).
So, the way Linux does it is not bad at all, but the way programmers
fail to initialize the memory as soon as it's allocated *is* bad.
Allocate the memory and initialize it when it's allocated, not later on
when you *might* use it. That way, it's there up front, before the long
computation, and there's no surprises half way through. (This is why the
C or C++ compiler warns about uninitialized objects.)
PGA
--
Paul G. Allen, BSIT/SE
Owner, Sr. Engineer
Random Logic Consulting Services
www.randomlogic.com
--
KPLUG-List@kernel-panic.org
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
