Re: New memory exhausted problem

[Daniel Oberhoff]

No, not directly. Theoretically It's 4GB in 32bit applications (and I  
haven't seen a 64bit octave yet). This is the "virtual adress space"  
of the process. This is independant on the amount of ram in your  
system (i.e. "virtual", it can be 90% swapped if you have very little  
ram...). But all of the libraries that it uses and probably some  
kernel related stuff are also mapped into that space. I think usually  
in the end you have a 2GB block left. But as jwe said: it's probably  
not in one piece. Especially octave generates _lots_ of small  
allocations/deallocations in the parser, which probably results in  
some fragmentation. And once you ask for such a big block and the MMU  
tells you it's not available you get the "memory exhausted". It won't  
try to swap because that wouldn't help. And it also can't go and  
defragment that space since that would invalidate pointers.

A good question would be: do you really need such a huge block? Can  
you use sparse matrices instead? Can you use a smaller datatype such  
as int32, int16, int8?

If not you have to keep bugging octave coders to make octave 64bit  
ready (and in the meantime upgrade your own system to 64bit) :).

Am 14.08.2007 um 05:49 schrieb Dmitri A. Sergatskov:

> Is not there "2GB per process" limit on i386?
> I suspect that one can run two octave processes
> each allocating 1.8GB...
>
> Sincerely,
>
> Dmitri.
> --
> _______________________________________________
> Help-octave mailing list
> address@hidden
> https://www.cae.wisc.edu/mailman/listinfo/help-octave

Daniel