I have worked out a very simple method for tracking the "memory
growth" of a process at run time.  It involves a header file and a
shell script.

Here's the header file:
////////// Header File Begin ///////////////
#ifndef _VIRTMEMINFO_H_
#define _VIRTMEMINFO_H_

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

#define VMEM_BUF_SIZE 200
#define VMEM_ENV_VAR  "VMEM_ENV_VAR"
#define CHK_SIZE \
                 { \
                   if(char* envVar=getenv(VMEM_ENV_VAR)) \
                   { \
                     char buf[VMEM_BUF_SIZE]; \
                     sprintf(buf, "%s %s %d %d %d %d", envVar, \
                             __FILE__, __LINE__, \
                             getpid(), getppid(), getpagesize()); \
                     system(buf); \
                   } \
                 }

#endif //_VIRTMEMINFO_H_
////////// Header File End ///////////////


Here's the shell script:
////////// Shell-script Begin ///////////////
#!/bin/ksh
#
# $1: Filename
# $2: Linenumber
# $3: Process id
# $4: Parent process id
# $5: Page Size

echo "File: $1, Line: $2"
echo "Page size is $5"
ps -elf | head -1; ps -elf | grep -w $3 | grep -w $4
echo "\n\n"
////////// Shell-script End ///////////////


By interspersing the above symbolic definition within my code, I am
able to correctly track the memory "growth", but I am not able to see
the memory "shrinkage", as the following coding example shows.  Can
someone explain why?

////////// Code-snippet Begin ///////////////
#include "virtmeminfo.h"

main()
{
  CHK_SIZE
  char *buf = new char[100000];
  CHK_SIZE
  delete [] buf;
  CHK_SIZE
}
////////// Code-snippet End ///////////////

Regards,
Bhat

"Generic Usenet Account" <usenet@sta.samsung.com> wrote in message
news:90e5135.0404051406.1d1c76b0@posting.google.com...
> I have worked out a very simple method for tracking the "memory
> growth" of a process at run time.  It involves a header file and a
> shell script.
>
> Here's the header file:
> ////////// Header File Begin ///////////////
> #ifndef _VIRTMEMINFO_H_
> #define _VIRTMEMINFO_H_
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/types.h>
> #include <unistd.h>
>
> #define VMEM_BUF_SIZE 200
> #define VMEM_ENV_VAR  "VMEM_ENV_VAR"
> #define CHK_SIZE \
>                  { \
>                    if(char* envVar=getenv(VMEM_ENV_VAR)) \
>                    { \
>                      char buf[VMEM_BUF_SIZE]; \
>                      sprintf(buf, "%s %s %d %d %d %d", envVar, \
>                              __FILE__, __LINE__, \
>                              getpid(), getppid(), getpagesize()); \
>                      system(buf); \
>                    } \
>                  }
>
> #endif //_VIRTMEMINFO_H_
> ////////// Header File End ///////////////
>
>
> Here's the shell script:
> ////////// Shell-script Begin ///////////////
> #!/bin/ksh
> #
> # $1: Filename
> # $2: Linenumber
> # $3: Process id
> # $4: Parent process id
> # $5: Page Size
>
> echo "File: $1, Line: $2"
> echo "Page size is $5"
> ps -elf | head -1; ps -elf | grep -w $3 | grep -w $4
> echo "\n\n"
> ////////// Shell-script End ///////////////
>
>
> By interspersing the above symbolic definition within my code, I am
> able to correctly track the memory "growth", but I am not able to see
> the memory "shrinkage", as the following coding example shows.  Can
> someone explain why?
>
> ////////// Code-snippet Begin ///////////////
> #include "virtmeminfo.h"
>
> main()
> {
>   CHK_SIZE
>   char *buf = new char[100000];
>   CHK_SIZE
>   delete [] buf;
>   CHK_SIZE
> }
> ////////// Code-snippet End ///////////////
>
> Regards,
> Bhat

I don't think that there is any requirement that deleting objects or
otherwise de-allocating memory should cause the operating system to reclaim
that memory immediately.  As far as I now, it may do so immediately, or
if/when needed by other processes, or after the program exits.  I'm pretty
sure it's operating system dependent (and possibly implementation dependent
as well).

-Howard

>> By interspersing the above symbolic definition within my code, I am
>> able to correctly track the memory "growth", but I am not able to see
>> the memory "shrinkage", as the following coding example shows.  Can
>> someone explain why?

There is no guarantee that there *IS* any "shrinkage".  The process
might not give back any memory to the OS until the program calls
exit(), and even that's not required by ANSI C (but good OS design
argues against massive memory leaks every time you run a program).

Some people argue that such "shrinkage" is *PROHIBITED* by ANSI C.
The argument goes like:  if the program gives it back, it might not
be able to get it again, and this violates the ANSI C mandate that
the memory be available for reallocation (which means by the SAME
program, as in ANSI C, there isn't any concept of having more than
one running at the same time).

					Gordon L. Burditt

Generic Usenet Account wrote:

> I have worked out a very simple method for tracking the "memory
> growth" of a process at run time.  It involves a header file and a
> shell script.

Please remove comp.lang.c from the crossposting list for C++ code.
Please remove comp.lang.c from the crossposting list for unix-specific code.

Follow-ups so set.
I can see why you hide behind a pseudonym.

Howard wrote to (among others) comp.lang.c:

[Off-topic answer to off-topic question]
Please remove comp.lang.c from the crossposting list for C++ code.
Please remove comp.lang.c from the crossposting list for unix-specific code.

Follow-ups so set.

Generic Usenet Account wrote:

> ////////// Header File Begin ///////////////
> #ifndef _VIRTMEMINFO_H_
> #define _VIRTMEMINFO_H_

Identifiers beginning with an underscore followed by an uppercase letter 
(or another underscore) are reserved for the implementation for any use, 
and C & C++ programs are forbidden to use them. Never use an identifier 
with a leading underscore (or a sequence of two underscores anywhere in 
the name) unless you are sure you know what you are doing.

> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/types.h>
> #include <unistd.h>

Code using system-specific extensions is not welcome on comp.lang.c or 
comp.lang.c++.

> 
> main()

You need to specify the return type (which must be 'int') here. There is 
no longer an "implicit int" rule in either C or C++. C++ has been 
without this rule for something like 10 years. C for almost 5.

-Kevin
-- 
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Generic Usenet Account wrote:
 > I have worked out a very simple method for tracking the "memory
 > growth" of a process at run time.  It involves a header file and a
 > shell script.

First of all please do not cross-post such questions to comp.lang.c and 
comp.lang.c++ as it is off-topic.

> By interspersing the above symbolic definition within my code, I am
> able to correctly track the memory "growth", but I am not able to see
> the memory "shrinkage", as the following coding example shows.  Can
> someone explain why?

As others mentioned the program do not *have* to give the memory back to 
the OS while it runs.
The actual process goes like this (correct me if I make any mistakes):

The memory allocation functions of the standard library, usually request 
a block of memory from the OS with brk()/sbrk() and then deals out 
memory chunks to the program that calls malloc and friends.
When a memory request from the program exceeds the ammount of free 
memory in the malloc pool it calls sbrk() again to get more from the OS.
When a program calls free() the library takes that memory chunk and 
returns it to the free memory pool to be given back to the program in 
subsequent calls to malloc()
The actual memory that the OS dealt to malloc is reclaimed when the 
program exits.

-- 
John Tsiombikas (Nuclear / the Lab)
nuclear@siggraph.org
http://thelab.demoscene.gr/nuclear/

"John Tsiombikas (Nuclear / the Lab)" <nuclear@siggraph.org> wrote in message news:<1081226812.111890@athnrd02.forthnet.gr>...

> 
> As others mentioned the program do not *have* to give the memory back to 
> the OS while it runs.
> The actual process goes like this (correct me if I make any mistakes):
> 
> The memory allocation functions of the standard library, usually request 
> a block of memory from the OS with brk()/sbrk() and then deals out 
> memory chunks to the program that calls malloc and friends.
> When a memory request from the program exceeds the ammount of free 
> memory in the malloc pool it calls sbrk() again to get more from the OS.
> When a program calls free() the library takes that memory chunk and 
> returns it to the free memory pool to be given back to the program in 
> subsequent calls to malloc()
> The actual memory that the OS dealt to malloc is reclaimed when the 
> program exits.

I would like to report the following finding on my version of Linux
(kernel 2.4.17).

The memory manager does not "claim" dynamically released memory of
size less than 32 blocks.  However, it does "claim" dynamically
released memory of size greater than 32 blocks.

It appears that when the size of dynamically released memory is less
than 32 blocks, the freed memory remains available to the process for
subsequent calls to new/malloc as its "free store".  In other words,
even if we don't see a drop in the memory usage figure, we should not
see any increase in the size unless we allocate more memory than is
currently available in the "free store".  Kindly refer to the
following code snippet:

////////// Code-snippet begins /////////
#include "virtmeminfo.h"

#define EXPT_BUF_SIZE   127372
// When the EXPT_BUF_SIZE is 127372, the memory size is as follows:
// Line "A": 384
// Line "B": 415
// Line "C": 415 (same as Line "B" ---- no drop)

// When the EXPT_BUF_SIZE is increased 127373, the memory size is as
follows:
// Line "A": 384
// Line "B": 416
// Line "C": 384 (drops back to Line "A" value)

main()
{
CHK_SIZE  // Line "A"
  char *buf = new char[EXPT_BUF_SIZE];
CHK_SIZE  // Line "B"
  delete [] buf;
CHK_SIZE  // Line "C"
}
////////// Code-snippet ends  /////////



Thanks,
Bhat

usenet@sta.samsung.com (Generic Usenet Account) writes:

> "John Tsiombikas (Nuclear / the Lab)" <nuclear@siggraph.org> wrote in message news:<1081226812.111890@athnrd02.forthnet.gr>...
>
>> 
>> As others mentioned the program do not *have* to give the memory back to 
>> the OS while it runs.
>> The actual process goes like this (correct me if I make any mistakes):
>> 
>> The memory allocation functions of the standard library, usually request 
>> a block of memory from the OS with brk()/sbrk() and then deals out 
>> memory chunks to the program that calls malloc and friends.

[snip]

>
> I would like to report the following finding on my version of Linux
> (kernel 2.4.17).
>
> The memory manager does not "claim" dynamically released memory of
> size less than 32 blocks.  However, it does "claim" dynamically
> released memory of size greater than 32 blocks.
>

Linux uses mmap()/munmap() for large memory blocks and brk()/sbrk() for
smaller ones.

Bye, Dragan


-- 
Dragan Cvetkovic, 

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

!!! Sender/From address is bogus. Use reply-to one !!!