[Octave-patch-tracker] [patch #9924] Suggestion for a memory() function

[Lars Kindermann]

Follow-up Comment #4, patch #9924 (project octave):

When the memory function was introduced in Matlab, systems were 32Bit at most.
On 32Bit systems the virtual address space of every process can be 4GB at
most, on linux typically 3GB are made available to the user, 1GB is reserved
for the kernel. So the availabe memory (MemAvailableAllArrays) = min(availabe
virtual memory, availabe system memory). And MaxPossibleArrayBytes is the
largest contiguous memory block, which tends to become smaller by
fragmentation. So the Ram available to a process can be smaller than the
physical memory availabe on the system. 

I'm not aware of an api call to get the lagest contiguous memory block, so I
don't compute MaxPossibleArrayBytes on 32Bit. You could try to malloc
increasingly smaller blocks until it succeeds...

On 64Bit systems it starts pretty easy. You have a virtual address space of
2^63Bytes (smaller on actual hardware). All available ram and swap can be
mapped into this. Fragmentation is avoided by mapping a new array to a new
location. So MaxPossibleArrayBytes, MemAvailableAllArrays,
SystemMemory.Available are typically about the same. And RamAvailableAllArrays
can be the same as PhysicalMemoryAvailable.
But the kernel can impose restrictions of ram /swap usage for every process.
So not all the available Ram might be availabe to octave. But that's not
implemented yet.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/patch/?9924>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/