DLL memory usage?
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 30

Thread: DLL memory usage?

  1. #1
    Join Date
    Nov 2001
    Posts
    251

    DLL memory usage?

    If I load a Windows DLL using LoadLibrary(), is there a way to find out how much
    memory it's using (not its memory footprint)?

  2. #2
    Join Date
    Oct 2002
    Location
    Tel Aviv
    Posts
    149

    Re: DLL memory usage?

    Hi,

    One way (not very precise) is to do the following:
    Use task manager, processes tab.
    Look at your process's memory usage before and after you load the dll

  3. #3
    Join Date
    May 2000
    Location
    KY, USA
    Posts
    18,652

    Re: DLL memory usage?

    Quote Originally Posted by Syslock
    If I load a Windows DLL using LoadLibrary(), is there a way to find out how much
    memory it's using (not its memory footprint)?
    What do you mean with using?
    Ciao, Andreas

    "Software is like sex, it's better when it's free." - Linus Torvalds


    Article(s): Allocators (STL) Function Objects (STL)

  4. #4
    Join Date
    Nov 2001
    Posts
    251

    Re: DLL memory usage?

    Allocated global memory usage? stack memory usage? Not possible?

  5. #5
    Join Date
    Sep 2002
    Location
    14 39'19.65"N / 121 1'44.34"E
    Posts
    9,815

    Re: DLL memory usage?

    Quote Originally Posted by Syslock
    Allocated global memory usage? stack memory usage? Not possible?
    A DLL is loaded into the memory space of the calling process - it has no own memory space. The calling process remains the same, it just executes code which is loaded from the DLL. So how would you distinguish which DLL "allocates" the memory? Or, to look at it the other way round: Since all of your code (be it in the exe or the DLL) lastly does its allocations by calling memory management functions in the VC runtime libs: Would you expect to see that the runtime DLL does all of the allocations, and the exe and other DLLs none?

  6. #6
    Join Date
    Oct 2002
    Location
    Germany
    Posts
    6,205

    Wink Re: DLL memory usage?

    Quote Originally Posted by Syslock
    Allocated global memory usage?
    Look up the WinAPI HeapQueryInformation to view your Application's heap usage, or GlobalMemoryStatus to view system-wide memory usage.
    Quote Originally Posted by Syslock
    stack memory usage? Not possible?
    Perhaps, querying Stack Usage does not make sense.

    Stack contains statically allocated data. Querying stack-space used can be of academic/statistical interest - but, no run-time decision can be made on the basis of this number...

    The heap in contrast is used for dynamically allocated objects. Hence, querying heap size is often necessary.

    Unlike heap, a Process, or a function always starts with a fixed, set stack size. The stack grows downwards and not upwards.

    For example, if the stack pointer (SP) at the start of a method points to -
    0x0FFF3344
    After inserting an integer, it will point to -
    0x0FFF3340
    The Stack Pointer always has a lower limit that must not be exceeded.
    Last edited by Siddhartha; November 4th, 2005 at 05:56 AM.

  7. #7
    Join Date
    Sep 2002
    Location
    14 39'19.65"N / 121 1'44.34"E
    Posts
    9,815

    Re: DLL memory usage?

    Quote Originally Posted by Siddhartha
    Stack contains statically allocated data.
    Sorry, but that's not correct. Automatic variables are created on the stack - while static data has the same lifetime as your program, objects on the stack are created and deleted at runtime, as blocks of your code are entered and left.

    Quote Originally Posted by Siddhartha
    - but, no run-time decision can be made on the basis of this number...
    Reason: Stack Size, Allocation and Usage is determined at compile-time.
    No, not really. The usage of the stack depends on the flow of control through your code (which blocks are entered, and the local variables declared inside that block). And especially for recursive calls, it can make sense to monitor stack usage, so you have an additional criterion to end the recursion before a stack overflow occurs.

  8. #8
    Join Date
    Nov 2001
    Posts
    251

    Re: DLL memory usage?

    Look up the WinAPI HeapQueryInformation to view your Application's heap usage, or GlobalMemoryStatus to view system-wide memory usage.
    HeapQueryInformation must be new, at least not in my older SDK. Requires Windows XP.

    I see there's a newer SDK out last time I checked:
    Microsoft Platform SDK, Windows XP SP2 August 2004 Edition

    Should get it soon.

  9. #9
    Join Date
    Oct 2002
    Location
    Germany
    Posts
    6,205

    Wink Re: DLL memory usage?

    Quote Originally Posted by gstercken
    Sorry, but that's not correct. Automatic variables are created on the stack - while static data has the same lifetime as your program, objects on the stack are created and deleted at runtime, as blocks of your code are entered and left.
    Yes, you are right here.
    I wanted to edit my post... but, was too sleepy, and you were faster!

    The point I am making is that the size of the stack is fixed.

    When a function starts, it starts with a set stack space of say 1 MB, and the pointer value reduces as stack usage increases. The stack is a downward growing array.
    This is in contrast with the heap that can theoretically grow to a limit of 4GB.

    I don't know of any stack usage measurement API.
    I heard of something like _chkstk () and it does not work.
    Quote Originally Posted by gstercken
    And especially for recursive calls, it can make sense to monitor stack usage, so you have an additional criterion to end the recursion before a stack overflow occurs.
    Actually, NO.

    In a recursive function, each recursive call results in a new stack to be created. In no case can you ever make an intelligent decision as to when the recursion should stop, as you will measure the stack usage of the current function stack, but not one of the stack in the next recursion (that will be a new stack).

    The maximum stack usage of a Process is also 4 GB, and therefore, creating a new stack is rarely a problem. Most stack problems occur in overflows in existing stacks, as their sizes are fixed and they cannot be expanded.
    Last edited by Siddhartha; April 19th, 2005 at 05:48 AM.

  10. #10
    Join Date
    Sep 2002
    Location
    14 39'19.65"N / 121 1'44.34"E
    Posts
    9,815

    Re: DLL memory usage?

    Quote Originally Posted by Siddhartha
    In a recursive function, each recursive call results in a new stack to be created.
    A new stack? Every thread has its own stack - but when a function is called recursively, that same stack will be used for every call.

  11. #11
    Join Date
    Oct 2002
    Location
    Germany
    Posts
    6,205

    Wink Re: DLL memory usage?

    Quote Originally Posted by gstercken
    A new stack? Every thread has its own stack - but when a function is called recursively, that same stack will be used for every call.
    That is not correct.

    Every function call has it's own stack.
    At assembly-level invoking a thread is also a call to a function.

    Both invoke the call opcode.

    A process starts with a fixed stack space, The top of a stack is pointed to by the ESP (Extended Stack Pointer) register - always, and this is a decrementing pointer.

    Every function calls results in a stack created for the function inside this Process Stack. This function-stack is also visible in the Developer Studio IDE, as the function call-stack, and therefore you can view variables local to a function, even at the N-th level of recursion.
    Last edited by Siddhartha; April 19th, 2005 at 07:41 AM. Reason: clarified...

  12. #12
    Join Date
    Sep 2002
    Location
    14 39'19.65"N / 121 1'44.34"E
    Posts
    9,815

    Re: DLL memory usage?

    Quote Originally Posted by Siddhartha
    Every function calls results in a stack created for the function inside this Process Stack. This function-stack is also visible in the Developer Studio IDE, as the function call-stack, and therefore you can view variables local to a function, even at the N-th level of recursion.
    OK, I see where your confusion comes from. What you are talking about is a stack frame. The stack (the one which is allocated for every thread under Win32) is divided into contiguous pieces called stack frames - and a new frame (not a new stack) is made for every call and eliminated when the call returns.

  13. #13
    Join Date
    Oct 2002
    Location
    Germany
    Posts
    6,205

    Wink Re: DLL memory usage?

    Quote Originally Posted by gstercken
    OK, I see where your confusion comes from. What you are talking about is a stack frame. The stack (the one which is allocated for every thread under Win32) is divided into contiguous pieces called stack frames - and a new frame (not a new stack) is made for every call and eliminated when the call returns.
    I am not confused.
    You are talking of Stack in the Windows Terminlogy .

    So far as the hardware and the Micro-Processor is concerned - a Stack is a Stack - whether it belongs to a Function, a Thread or a Process.
    The sizes are different, and the addresses are different. That's all.

    They are all, without exception, addressed by ESP register.

    The Micro-Processor does not differentiate, MSDN does.

  14. #14
    Join Date
    Sep 2004
    Location
    A Planet Called Earth... :-)
    Posts
    835

    Question Re: DLL memory usage?

    Hi,


    I have been reading ur post here, and i want to know where can i read so much about stack..., free store..., windows memory management??? I have read memory management from msdn, and i look at it only as an introduction.
    So any links w'd be gr8

    bye

  15. #15
    Join Date
    Sep 2004
    Location
    A Planet Called Earth... :-)
    Posts
    835

    Question Re: DLL memory usage?

    Quote Originally Posted by gstercken
    A DLL is loaded into the memory space of the calling process - it has no own memory space. The calling process remains the same, it just executes code which is loaded from the DLL. So how would you distinguish which DLL "allocates" the memory? Or, to look at it the other way round: Since all of your code (be it in the exe or the DLL) lastly does its allocations by calling memory management functions in the VC runtime libs: Would you expect to see that the runtime DLL does all of the allocations, and the exe and other DLLs none?
    If i call a dll from another system, using com/dcom, where is the dll allocated in memory?????

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This a Codeguru.com survey!


On-Demand Webinars (sponsored)