Re: Memory issue
On Aug 11, 11:52 am, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Aug 10, 9:09 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* kathy:
I want to use std::vector::pushback function to keep data
in RAM. What will happened if no more memory available?
In practice, what happens on a modern system as free memory
starts to become exhausted and/or very fragmented, is that
the system slows to a crawl, so, you're unlikely to
actually reach that limit for a set of small allocations.
On modern systems, it's not rare for the actual memory to be
the same size as the virtual memory, which means that in
practice, you'll never page.
No, that theory isn't practice.
It is on two of the systems I have before me: Solaris and
Windows. Linux has some tweaks where it will over allocate, but
if the size of the virtual memory is equal to the size of the
real memory (using Unix terminology---I would have said that the
size of the virtual memory is 0, and all memory is real), then
you'll never page. It's quite possible to run Solaris (and
probably Windows) with no disk space allocated for virtual
memory.
I think what you would have meant to write, if you thought
about it, would have been "which means that, provided there
are no other processes using much memory, an ideal OS won't
page". And some systems may work like that, and when you're
lucky you don't have any other processes competing for actual
memory. :-)
No. The system has a fixed resource: virtual memory. In the
usual Unix terminology, the "size" of the virtual memory is the
size of the main memory, plus the size(s) of the swap partitions
(called tmpfs under Linux). For various reasons, it's very
unusual to run without swap/temporary partition, but it's
possible to configure the system to do so. And if you do, the
size of the virtual memory is equal to the size of the real
memory, and you never page anything out.
Andy Chapman's comment else-thread was more relevant, I think.
Because with enough RAM you can conceivably hit the limit of
the address space and get a std::bad_alloc before the OS
starts trashing.
That's a likely case with Windows, where you can only access
half of the available address space. But you should also be
able to configure the system so that it doesn't use more than
the available main memory.
(4GB for both seems to be a common figure, even on 64 bit
systems.) The phenomenon you describe would mainly apply to
older systems.
Well, my experience and interest in recent years has mostly
been with Windows.
AFAIK it's quite difficult to make Windows refrain from paging.
This is a problem for some people implementing Windows based
servers.
I can imagine it would be. Perhaps the reason I'm so sure that
this can be done is that I work on large scale, high performance
servers, where we can't tolerate paging. But they're all Unix
systems---the only ones I've actually been involved in at that
level have been Sun OS and Solaris.
However, a very large allocation might fail.
Or not. Some OS's don't tell you when there's not enough
virtual memory, in which case, the allocation works, but you
get a core dump when you use the memory.
Example?
Linux. AIX in some configurations. Reportedly HP/UX. I seem
to recall some wierd behavior from Windows NT as well.
This default response can be overridden in three ways:
* By replacing the class' operator new (this is just an
unfortunate name for the allocation function; it's
*called* by a 'new' expression, which after that call
proceeds to call the specified constructor, i.e. you're
not overriding what a 'new' expression does by defining
operator new).
Interestingly enough, this has absolutely no effect on
std::vector---std::vector< T > will always use ::operator
new, even if T has a class specific allocator.
Yeah, I lost the context of std::vector, sorry.
Actually, I think it's an interesting point. If I provide a
class specific allocator, it's because I want all of the memory
for objects of the class allocated with that allocator.
std::vector screws that.
It's something that hadn't occurred to me before.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34