Memory Collect leads to more memory usage?

[Kevin]

Hi!

In my program, the user has an option (a menu item) to issue the memory
collect, which calls a function like:

Runtime rt = Runtime.getRuntime();
rt.gc();

However, I observed that this call actually results in more memory
usage as reported from WinXP's task manager (the Page File Usage
History in the Performance tab).

Before the call, its shows about 900M memory current usage (the PC has
physical memory 1G, with plenty of virtual memory).
After the call, it jumps to 1100M and stays there. (more calls to the
memory collect does not affect it).

How to explain it?

Thanks ya!~

 

[Andrew Thompson]

Hi!

In my program, the user has an option (a menu item) to issue the memory
collect, which calls a function like:

Runtime rt = Runtime.getRuntime();
rt.gc(); ....
How to explain it?

Garbage is collected as and when the JVM needs to do it.

Calling GC is merely a *suggestion* that now is a good time to
do garbage collection, but if a VM has plenty of memory, it will
likely be ignored.

Further, calling GC will not free resources that still
have references.

The best way to achieve good memory management is to
ensire you do not hold on to references of objects
longer than necessary, and simply leave the VM to decide
when to collect garbage.

That is exactly what I do in 'The Giffer'* that has a memory bar
on the lower left to give you a crude idea of how (and when)
a typical VM handles GC.

* <http://www.physci.org/giffer/>
Note - the effect I am referring to is more obvious
in the 'Standard Memory' version..

HTH

 

[Kevin]

But that does not explain why the task manager reports 200M memory
usage increase: if gc is "lazy", we should observe not much change in
memory usage. Any idea of it?

 

[Mike Schilling]

Hi!

In my program, the user has an option (a menu item) to issue the memory
collect, which calls a function like:

Runtime rt = Runtime.getRuntime();
rt.gc();

However, I observed that this call actually results in more memory
usage as reported from WinXP's task manager (the Page File Usage
History in the Performance tab).

Before the call, its shows about 900M memory current usage (the PC has
physical memory 1G, with plenty of virtual memory).
After the call, it jumps to 1100M and stays there. (more calls to the
memory collect does not affect it).

The JVM uses virtual memory for several purposes, some of those being code,
memory used by the JVM's runtime, and the Java heap. Garbage collection
means making free space inside the last of these, but not, in general making
it smaller or returning any virtual memory to the OS. That is, even a very
successful GC will not result in the process using less VM.

In addition, it's quite possible that a garabge collection needs to allocate
memory for use by the collector. I suspect that's what you're seeing.

 

[asaguden]

This is no solution to your problem - I can only agree with other
responses.

A good idea is NOT to use 'Memory use' in the Task Manager - use
'Virtual Memory' instead. It gives a better report of actually used
memory by each
process, among these Java.

 

[HalcyonWild]

Garbage is collected as and when the JVM needs to do it.

Calling GC is merely a *suggestion* that now is a good time to
do garbage collection, but if a VM has plenty of memory, it will
likely be ignored.

Further, calling GC will not free resources that still
have references.

The best way to achieve good memory management is to
ensire you do not hold on to references of objects
longer than necessary, and simply leave the VM to decide
when to collect garbage.

Just a thought. Doesnt GC itself require some memory to run. On calling
gc(), the GC starts, and occupies some memory for its task of releasing
memory, and compacting it, a pretty heavy task. That might be the
reason for the memory usage jump shown by the task manager.

 

[Thomas Hawtin]

Just a thought. Doesnt GC itself require some memory to run. On calling
gc(), the GC starts, and occupies some memory for its task of releasing
memory, and compacting it, a pretty heavy task. That might be the
reason for the memory usage jump shown by the task manager.

Depending on the algorithm, gc will usually require some stack space.
That will usually be preallocated. On Sun's implementation, object
copying will often be from a survivor space to the tenured generation,
which may require the latter to be expanded.

I don't know much about Windows' reporting of memory usage. Possibly
what is shown results from garbage collection forcing loading of swapped
pages. Loading those pages may require others to be swapped out. Pages
swapped out may not have been swapped out before. The increase in the
reported figure may just be pages getting flushed out, rather than any
extra allocations.

Tom Hawtin

 

[Stephen Kellett]

However, I observed that this call actually results in more memory
usage as reported from WinXP's task manager (the Page File Usage
History in the Performance tab).

It is quite possible that memory space usage will temporarily increase
due to the workspace required to run the GC. The mistake with using Task
Manager to measure memory usage is assuming that because the C runtime
(which implements your JVM) has freed some memory that the C runtime has
actually returned the memory to the OS (it most likely has not been
returned to the OS). So although the memory used by your app may have
gone down, the OS view of this memory may be radically different. You
need a different view:

Do not use Task Manager to measure memory usage as you will be including
the memory space for Threads (1MB per thread), DLLs, shared memory, etc.
As a result Task Manager is an unreliable tool for measuring memory
usage. If you want to view your application's memory space download VM
Validator (free) from

http://www.softwareverify.com
http://www.softwareverify.com/vmValidator/index.html

You get two views onto your application's memory:
1) Page Table view - showing you which 4K pages are paged in/out
2) Virtual Memory view - showing your the Windows memory states for each
page, including identifying reserve/commit/release/dll memory spaces.

Stephen