www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1993/07/12/04:09:46

From: kunst AT prl DOT philips DOT nl
Subject: Re: available memory
To: jweiss AT silver DOT sdsmt DOT edu (John M. Weiss)
Date: Mon, 12 Jul 1993 09:05:35 +0100 (METDST)
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu (DJGPP users list)

John M. Weiss writes:
> 
> > Does anyone know how to query the amount of available physical RAM
> > using gcc? Turbo C provides the coreleft() routine, but this is not
> > part of the standard C libraries. I seem to remember seeing some code
> > that made use of brk/sbrk to do this once upon a time...
> 
> Motivation for the above:
> I am writing an image processing program that makes use of 2-D fast
> Fourier transforms. 2-D FFT's are very memory-intensive, involving
> complex Fourier coefficients (i.e., 8 bytes per pixel). 

***************************************************************************
> This memory gets allocated/deallocated dynamically with malloc()/free(). 
***************************************************************************

> Although
> in-memory FFT's are not too bad, even the so-called "fast" transform is
> *extremely* slow if disk-swapping is required. Therefore it is important
> for me to know in advance whether or not I have enough physical memory
> (not virtual memory) available to do everything in RAM.
> 
> Any suggestions? Thanks again - JW
> 

I had more or less the same requirement for my memory hungry programs.
What I did is rather simple: I added my own wrapper functions around 
'malloc()' and 'free()', and added an extra function which calculates
the amount of memory currently allocated. It works fine. The total amount 
of available physical memory is displayed when you use 'debug32' to run 
the program. 

Another reason for this approach is that you can add extra checks in
'free()' to prevent "releasing" memory which was not obtained by a 
previous call to 'malloc()', and at exit of your program you can check
for "memory leaks" (blocks of memory which are not freed by the program).
"Memory leaks" in a program can be a serious source for unexpected swapping.


 .^^^^^^^^           _____________________________________
 |      |          / Pieter Kunst (P.J.)                   \
 |  _  _|        /   Philips Research Laboratories,          \
.--(o)(o)      /     Building WY3, Prof. Holstlaan 4,         \
|@      _)   /       5656 AA  Eindhoven, The Netherlands.      |
  | ,___|   /        e-mail: kunst AT prl DOT philips DOT nl             /
  |   /     \_______________________________________________/
  /____\

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019