Tracking the "memory growth" of a process

Discussion in 'C++' started by Generic Usenet Account, Apr 5, 2004.

  1. 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, Apr 5, 2004
    #1
    1. Advertising

  2. Generic Usenet Account

    Howard Guest

    "Generic Usenet Account" <> wrote in message
    news:...
    > 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
     
    Howard, Apr 5, 2004
    #2
    1. Advertising

  3. >> 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
     
    Gordon Burditt, Apr 5, 2004
    #3
  4. 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.
     
    Martin Ambuhl, Apr 6, 2004
    #4
  5. 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.
     
    Martin Ambuhl, Apr 6, 2004
    #5
  6. 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.
     
    Kevin Goodsell, Apr 6, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rithesh Pai
    Replies:
    1
    Views:
    5,609
  2. walala
    Replies:
    3
    Views:
    752
    Allan Herriman
    Sep 9, 2003
  3. rtm
    Replies:
    0
    Views:
    805
  4. Generic Usenet Account

    Tracking the "memory growth" of a process

    Generic Usenet Account, Apr 5, 2004, in forum: C Programming
    Replies:
    4
    Views:
    338
    Kevin Goodsell
    Apr 6, 2004
  5. Replies:
    3
    Views:
    1,034
    Martin Honnen
    Dec 20, 2006
Loading...

Share This Page