Ben_ schrieb:
> It was feeling that it's by design that memory was not released, because
> shrinking the heap and releasing memory to OS are two different things.
>
> I didn't know it for sure, so I didn't tell it. But now, I found the
> following in the IBM JVM Diagnostic Guide 1.4.2, p.20, Heap shrinkage:
The following sentice is exactly what we expected.
> "
> No virtual space from the heap is ever freed
> back to the native operating system. When the heap shrinks, it shrinks
> inside the
> original virtual space.
No problem with that. The jvm can allocate 8GiByte virtual memory all
the time, but
> Whether any physical memory is released depends on the ability of the native
> operating system. If it supports paging; that is, the ability of the native
> operating
> system to commit and decommit physical storage to the virtual storage, the
> Garbage Collector uses this function. In this case, physical memory can be
> decommitted on a heap shrinkage.
that does not occur. The unused _physical_ pages to are not released.
> Other pointers:
> http://www.ibm.com/developerworks/eserver/library/es-javaonaix_memory.html
It's unbelievable, how do you find this nice page ... I have to order a
google lead in :-))
> http://www.jguru.com/faq/view.jsp?EID=478232
This discussion is a little bit older. The fist JVMs have not the
functionality to release memory.
> I'm not an AIX'er, but it looks from svmon man page that it "captures and
> analyzes a snapshot of virtual memory"
A snapshot is all what we need.
> (http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds5/svmon
> .htm). So, as the Guide indicates, you won't see decreases.
With a little bit caclulation svmon shows also the used physical memory
pages.
> BTW, in a post or another, I read a suggestion that one could spawn a
> separate java process for the heap consuming task. Or, if the application is
> monitored by a watchdog, commit suicide and let it restart.
Yes, we are thinking about that, but this should be the last step ...
Bye Thomas