Hi,

I need the available memory (heap). At that time the functions maxavail or memavail did this. I read that I should use GetFPCHeapStatus and other function currently.

This functions produce allways zero!! What can I do? What is wrong? I use fpc version 2.2.0 [2008/05/27] for i386.

Here is some source and output to describe the problem:

program memory;
var
  a:TFPCHeapStatus;
  b:THeapStatus;
begin
  a:=GetFPCHeapStatus;
  writeln(a.MaxHeapSize);
  writeln(a.MaxHeapUsed);
  writeln(a.CurrHeapSize);
  writeln(a.CurrHeapUsed);
  writeln(a.CurrHeapFree);
  writeln('-----');
  b:=GetHeapStatus;
  writeln(b.TotalAddrSpace);
  writeln(b.TotalUncommitted);
  writeln(b.TotalCommitted);
  writeln(b.TotalAllocated);
  writeln(b.TotalFree);
  writeln(b.FreeSmall);
  writeln(b.FreeBig);
  writeln(b.Unused);
  writeln(b.Overhead);
  writeln(b.HeapErrorCode);
  writeln('#################-----');
  a:=SysGetFPCHeapStatus;
  writeln(a.MaxHeapSize);
  writeln(a.MaxHeapUsed);
  writeln(a.CurrHeapSize);
  writeln(a.CurrHeapUsed);
  writeln(a.CurrHeapFree);
  writeln('-----');
  b:=SysGetHeapStatus;
  writeln(b.TotalAddrSpace);
  writeln(b.TotalUncommitted);
  writeln(b.TotalCommitted);
  writeln(b.TotalAllocated);
  writeln(b.TotalFree);
  writeln(b.FreeSmall);
  writeln(b.FreeBig);
  writeln(b.Unused);
  writeln(b.Overhead);
  writeln(b.HeapErrorCode);
end.

This source generate the following output:

0
0
0
0
0
-----
0
0
0
0
0
0
0
0
0
0
#################-----
0
0
0
0
0
-----
0
0
0
0
0
0
0
0
0
0

On which OS? And what happens if you allocate some memory at the start of your program?

Anyway, even if it would return non-zero values, the information would be next to useless. The reason is that on modern OS'es, available physical memory is dynamically divided between the disk cache and applications, with a lower limit on the disk cache. What would you expect memavail to report? The current amount of really "free" memory? Free + cache? Free + part of cache? Free + non-wired (i.e., swappable)
+ part of cache? Free + non-wired + part of cache + swap space?

The information provided by GetFPCHeapStatus is only useful to get statistics about the heap manager, and not to get any information about the system you are running on.

Jonas

Hi Jonas,

thank you for your answer.

On which OS?

Debian 5.0 GNU/Linux (uname -r: 2.6.26-1-686)

Anyway, even if it would return non-zero values, the information would be next to useless. The reason is that on modern OS'es, available physical memory is dynamically divided between the disk cache and applications, with a lower limit on the disk cache.

...

The information provided by GetFPCHeapStatus is only useful to get statistics about the heap manager, and not to get any information about the system you are running on.

I have misunderstood this. Ok, thank you.

And what happens if you allocate some memory at the start of your program? What would you expect memavail to report? The current amount of really "free" memory? Free + cache? Free + part of cache? Free + non-wired (i.e., swappable) + part of cache? Free + non-wired + part of cache + swap space?

I need the really "free" memory. I would use the maximal available free working memory (no swap or so) because I need a program-internal quick (very very quick) memory as a cache as soon as practicable. I would cache streams of measurement values (single type, sample rate circa 32KHz). The measurement program will run on diffrent machines with diffrent RAM. Depending on the free memory the number of measurement values or the measurement times are diffrent. The reason to know the free memory is to decide what or how should I measure. All buffered prints into a file are to slow and produce underruns. My idea is to stream the measurement values into an array and write the array on disk after the measurement. To do this I must know the memory ;-)

Is there a other way to get the free memory size?

Thanks
Markus

In our previous episode, Markus Glugla said:

As Jonas said you first have to define that value in a multitasking environment.

Hi,

Marco van de Voort wrote

As Jonas said you first have to define that value in a multitasking environment.

Ok, I have allocate the memory at the program start and it runs fine. It is quick enough yet with memory swaping.

But, if I allocate 2GB memory the program crashs with an access violation. I have read that fpc can handle arrays up to a size of 2GB, isn't? How great can be an array?

Thanks, Markus

Markus Glugla wrote

But, if I allocate 2GB memory the program crashs with an access violation. I have read that fpc can handle arrays up to a size of 2GB, isn't? How great can be an array?

First of all, you set the global system unit variable 'ReturnNilIfGrowHeapFails' to true, so that instead of a run time error (or exception) you will simply get nil if a memory allocation fails.

Secondly, not being able to allocate an array of 2GB is unrelated to FPC, but due to the fact that you are (most likely) working on a 32 bit OS. While the theoretical maximum limit for 32 bit systems is 4GB, it is impossible to ever allocate that much memory in a s single block.

The reason is that while your program runs in its own virtual memory space, it is not the only thing in that space. The kernel usually takes part of the memory (512MB to 1GB), your program code, data and stack take part of it (and not contiguously; e.g., the code and data usually start somewhere around address 0x804000, while the stack starts at 0xC0000000 and grows downwards from there), and then there are shared libraries which can be mapped all over the place.

As a result, the virtual memory space is fragmented already right after your program starts, and on most 32 bit systems you seldom can allocate more than 1.5GB of contiguous memory (simply because other things are in the way otherwise), and sometimes even less.

Jonas

Hi Jonas,

First of all, you set the global system unit variable 'ReturnNilIfGrowHeapFails' to true, so that instead of a run time error (or exception) you will simply get nil if a memory allocation fails.

This is a very good tip! I have read about 'ReturnNilIfGrowHeapFails' but I forget it. I think, it is a good solution for my problem.

Secondly, not being able to allocate an array of 2GB is unrelated to FPC, but due to the fact that you are (most likely) working on a 32 bit OS. While the theoretical maximum limit for 32 bit systems is 4GB, it is impossible to ever allocate that much memory in a s single block.

Yes, it finally sunk in. I see clearlier the context of memomry management. Thanks.

Ok, thats new for me. It is very interesting.

As a result, the virtual memory space is fragmented already right after your program starts, and on most 32 bit systems you seldom can allocate more than 1.5GB of contiguous memory (simply because other things are in the way otherwise), and sometimes even less.

My experience with the topic coincides with your sentences.

Finally, I think i understand some thinks better. Including with your first very good tip, I can fix the problem.

Thank you, Jonas, for your help.
Also Thank's to Marco.

Bye, Markus