Not a bug?
jesper.wilhelmsson at oracle.com
Mon Sep 23 11:09:13 PDT 2013
I have verified that G1, Parallel scavenge and ParallelOld do return memory when
the heap shrinks. I'm not so sure about Serial and CMS, they didn't shrink their
heap in my experiments.
Both parallel collectors do require a number of GCs before shrinking the heap
down to an "acceptable" size, this is per design. They are deliberately holding
on to the heap assuming that it will be needed in the future.
G1 is remarkably good at shrinking the heap fast, so for the usecase described
in the bug I would say it's solvable by using G1 and running System.gc() after
having released all cashes and class loaders etc.
I'll update the bug with this comment.
Would you agree that with that solution the bug can be closed?
Peter B. Kessler skrev 23/9/13 6:36 PM:
> Before you close that one you should check that all our collectors *do* release
> memory back to the operating system if an application drops references. The
> damping parameters might need some tweaking for the sizes of heaps we see now as
> opposed to when the parameters were last tuned. I think those parameters can be
> set on the command line, but I don't think they can be changed by a running
> application, which might be what the request is asking for.
> It would be interesting to know whether recovering 1GB of heap from swap space
> is more efficient than rebuilding a 1GB heap from breadcrumbs left in a
> "minimized" application. That is: does the operating system already provide
> adequate functionality for this RFE? I suspect that the answer is: "It depends
> on the application." (It probably also depends on the operating system.)
> ... peter
> On 09/23/13 08:41, Jesper Wilhelmsson wrote:
>> I stumbled across this RFE: JDK-6498735: JVM should be able to fully release
>> allocated memory
>> I agree with Peter's assessment in the bug that it should be closed as "not a
>> bug". What do others think?
More information about the hotspot-gc-dev