When will G1 shrink the heap?
Paul Richards
paul.richards at gmail.com
Tue Apr 12 21:11:35 UTC 2016
Very interesting, thanks for your response.
Was this documented somewhere that I missed? It sounds like you
needed to dig into source code to get the answer.
Has this issue been considered much in the context of the proposal to
switch the JVM default to G1 in Java 9? If so, would that be
documented somewhere that I could go read?
The previous default, the parallel collector, does shrink the heap in
practice. The ergonomics docs state that if all other goals are met
then the heap is shrunk [1]. It may only be on full GC events (I'm
not sure), but unlike G1 these are expected and not avoided by the
parallel collector. The ability for the JVM to shrink the heap is an
important feature that it would be a shame to lose in the default
configuration, imho. It would turn a great deal of Java applications
that use the default configuration into bad citizens, greedily and
needlessly holding on to their peak memory requirements until program
end.
[ In my own application (as a small-fry example), there is some
computation at startup which requires raised memory usage. After this
point a simple event loop is entered with a far smaller amount of data
being retained in heap. It would be poor for this application if the
memory acquired at startup was never released to the OS, as it's
beneficial for this application if there is a reasonably sized page
cache. Of course I can manually configure GC options to avoid this
happening in Java 9, but that is beside the point as many applications
use the defaults. ]
1: https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/parallel.html#parallel_collector_priority
"In addition, the collector has an implicit goal of minimizing the
size of the heap as long as the other goals are being met."
On 12 April 2016 at 21:06, Yu Zhang <yu.zhang at oracle.com> wrote:
> Paul,
>
> On 4/12/2016 11:54 AM, Paul Richards wrote:
>
> My understanding is that under normal circumstances G1 should only perform
> young and mixed GC cycles. A full GC should be a rare occurrence from what
> I read.
>
> Yes, for G1 we should try to avoid full gc.
>
> Combined with the information you've kindly provided, does this mean that G1
> will practically never shrink the heap if the system is running healthily?
>
> That is the case for now. This might change in the future.
>
> Thanks,
>
>
> On Tue, 12 Apr 2016 19:03 Yu Zhang, <yu.zhang at oracle.com> wrote:
>>
>> Paul,
>>
>> I checked both jdk8 and current jdk9. The heap is only shrinked after full
>> gc.
>> After full gc, there is a way to calculate maximum_desired_capacity (based
>> on used heap after full gc and historic data). If the committed heap is
>> bigger than the maximum_desired_capacity, then the heap shrinks.
>>
>> If you -XX:+PrintAdaptiveSizePolicy, you should see messages in the gc log
>> when shrinking happens.
>> "Attempt heap shrinking..."
>>
>> Thanks,
>> Jenny
>>
>> On 4/11/2016 11:24 AM, Paul Richards wrote:
>>
>> I try to track the latest stable release from Oracle. Currently we're
>> using Java SE 8u77.
>>
>> I will likely migrate to Java 9 when it is officially released, so it
>> would be interesting to know if your answer is different for Java 9.
>>
>> On 11 April 2016 at 18:20, Yu Zhang <yu.zhang at oracle.com> wrote:
>>
>> Paul,
>>
>> Which jdk version are you using?
>>
>> Thanks,
>> Jenny
>>
>> On 4/6/2016 6:13 AM, Paul Richards wrote:
>>
>> Hi there,
>> Under what circumstances will G1 decide to shrink the heap? I'm
>> hoping someone can point me to existing docs for this.
>>
>>
>>
>>
>>
>
--
Paul Richards
@pauldoo
More information about the hotspot-gc-use
mailing list