Tracking the "memory growth" of a process

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

re: Tracking the "memory growth" of a process

"Generic Usenet Account" <usenet@sta.samsung.com> wrote in message
news:90e5135.0404051406.1d1c76b0@posting.google.co m...[color=blue]
> 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[/color]

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

re: Tracking the "memory growth" of a process

"Generic Usenet Account" <usenet@sta.samsung.com> wrote in message
news:90e5135.0404051406.1d1c76b0@posting.google.co m...[color=blue]
> 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[/color]

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

re: Tracking the "memory growth" of a process

>> By interspersing the above symbolic definition within my code, I am[color=blue][color=green]
>> 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?[/color][/color]

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

re: Tracking the "memory growth" of a process

>> By interspersing the above symbolic definition within my code, I am[color=blue][color=green]
>> 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?[/color][/color]

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

re: Tracking the "memory growth" of a process

Generic Usenet Account wrote:
[color=blue]
> 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.[/color]

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.

re: Tracking the "memory growth" of a process

Generic Usenet Account wrote:
[color=blue]
> 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.[/color]

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.

re: Tracking the "memory growth" of a process

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.

re: Tracking the "memory growth" of a process

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.

re: Tracking the "memory growth" of a process

Generic Usenet Account wrote:
[color=blue]
> ////////// Header File Begin ///////////////
> #ifndef _VIRTMEMINFO_H_
> #define _VIRTMEMINFO_H_[/color]

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.
[color=blue]
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/types.h>
> #include <unistd.h>[/color]

Code using system-specific extensions is not welcome on comp.lang.c or
comp.lang.c++.
[color=blue]
>
> main()[/color]

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.

re: Tracking the "memory growth" of a process

Generic Usenet Account wrote:
[color=blue]
> ////////// Header File Begin ///////////////
> #ifndef _VIRTMEMINFO_H_
> #define _VIRTMEMINFO_H_[/color]

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.
[color=blue]
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/types.h>
> #include <unistd.h>[/color]

Code using system-specific extensions is not welcome on comp.lang.c or
comp.lang.c++.
[color=blue]
>
> main()[/color]

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.