Free ratio based heap shrinking in the parallel collector
Hiroshi Yamauchi
yamauchi at google.com
Thu Mar 18 19:01:59 UTC 2010
Jon,
Thanks for your comments.
On Tue, Mar 16, 2010 at 8:04 PM, Jon Masamitsu <Jon.Masamitsu at sun.com>wrote:
> I had forgotten the other half of this which was the behavior
> on System.gc(). I agree that it would be nice to have a way
> for the user to collapse the heap quickly if the user knows that
> the application is going to be inactive. The code you suggested
> only shrinks the heap. I think it would be more complete if it
> would also grow the heap according to MinHeapFreeRatio.
>
In practice, the expansion side isn't a problem in my experience. i.e., it
will expand eventually. Also, in the way the patch is written currently, the
expansion is taken care of by PSAdaptiveSizePolicy which I think does a good
job. That said, I agree that it'd be more complete if the MinHeapFreeRatio
part is implemented from the point of view of seeing MinHeapFreeRatio and
MaxHeapFreeRatio as a inseparable pair.
> I don't know the scenario where it would be used but I
> wouldn't be surprised if there is one. It would also make it
> practical to run UseParallelGC with UseAdaptiveSizePolicy
> turned off (the heap resizing would then be done similarly
> to the other collectors).
>
One scenario that I have for system.gc() as a hint for shrinkage is where
you have a daemon-like (background) process, running on your
desktop/workstation, that performs occasional batch type jobs. After each
job is done, it is highly likely that the process will be idle for a while
until a next job comes. It isn't the best if the idle background process is
occupying a large amount of (resident) memory. Another would be, if there is
some server that does a batch type of job (so, latency isn't a priority)
that could be idle for an extended period of time and there are other
processes on the same machine that could benefit from more free memory.
Do you mean that if one runs with -XX:+UseParallelGC and
-XX:-UseAdaptiveSizePolicy, the free ratio flags are honored by the parallel
collector or the heap shrinks in practice some other ways?
Thanks,
Hiroshi
> Jon
>
> Jon Masamitsu wrote On 03/16/10 15:38,:
>
> >Hiroshi,
> >
> >The goal of UseAdaptiveSizePolicy with regard to performance is
> >to size the generations so as to achieve the throughput goal.
> >GC cost is reduced by reducing the frequency of collections
> >and that is achieved by more free space in the generations
> >(more space for more allocations before the next GC).
> >
> >I can see how a user might want to limit the footprint. Without
> >your change I would tell the user to reduce the throughput goal.
> >Not a particularly friendly interface to limit footprint I'll
> >admit.
> >
> >There is a method
> >
> >PSAdaptiveSizePolicy::adjust_for_throughput()
> >
> >which is called to calculate the amount that the heap
> >should grow in order to achieve a throughput goal.
> >If that method said not to increase the heap based
> >on the value of MaxHeapFreeRatio is that close to
> >what you want? It's not the same but it would be
> >a way of limiting the growth of the heap (stops
> >growing the heap when the free space after the collection
> >exceeds a threshold). I think it would fit in more
> >easily with the rest of UseAdativeSizePolicy. I think
> >it would be easier to explain too.
> >
> >Jon
> >
> >On 03/15/10 16:50, Hiroshi Yamauchi wrote:
> >
> >
> >>On Mon, Mar 15, 2010 at 12:03 PM, Jon Masamitsu <Jon.Masamitsu at sun.com
> >><mailto:Jon.Masamitsu at sun.com>> wrote:
> >>
> >> Hiroshi,
> >>
> >> I'm looking at the code in psParallelCompact.cpp
> >>
> >> 2076 bool free_ratio_in_effect = false;
> >> 2077 if ((UseFreeRatioForParallelGC ||
> >> 2078 (UseFreeRatioOnlyInSystemGCForParallelGC &&
> >> 2079 gc_cause == GCCause::_java_lang_system_gc))) {
> >> 2080 ParallelScavengeHeap* heap =
> >> (ParallelScavengeHeap*)Universe::heap();
> >> 2081 free_ratio_in_effect =
> >> heap->try_to_shrink_by_free_ratio(true);
> >> 2082 }
> >> 2083
> >> 2084 if (!free_ratio_in_effect && UseAdaptiveSizePolicy) {
> >>
> >> If only UseFreeRatioForParallelGC is set to true, is it correct
> >> that the heap
> >>
> >> a) will grow according to the original UseAdaptiveSizePolicy
> >> policy until MaxHeapFreeRatio is exceeded (i.e., until
> >> try_to_shrink_by_free_ratio() returns true)
> >> b) will then shrink until MaxHeapFreeRatio is no longer exceeded
> >> (likely just that once)
> >>
> >> then start with a) again?
> >>
> >>
> >>I think that mostly matches my intention. The cyclical pattern
> >>(a->b->a->b->...) is assumed not to happen more often than necessary
> >>though. An expectation is that the value of MaxHeapFreeRatio is high
> >>enough (70 by default) that the b) only happens when the app is under
> >>reasonably light(er) load (or just idle.)
> >>UseFreeRatioOnlyInSystemGCForParallelGC (instead of
> >>UseFreeRatioForParallelGC ) is for apps that call System.gc() to give a
> >>hint about the need to have its heap shrunk and want to avoid heap
> >>shrinking otherwise.
> >>
> >>An intuition is the following. To reduce the memory footprint, the free
> >>ratio logic holds back the heap expansion if the original adaptive size
> >>policy expands too aggressively, or overrides and shrink the heap if the
> >>original adaptive size policy leaves too much free space, in terms of
> >>the value of MaxHeapFreeRatio. I think it's not far from what flag
> >>MaxHeapFreeRatio originally meant. Otherwise, the heap size depends on
> >>the original adaptive size policy (for performance.) It's a tradeoff
> >>between performance and footprint.
> >>
> >>
> >> What type of application fits with such a combination of policies?
> >> Do you have a plots of how the heap sizing behaves (i.e., size of the
> >> generations vs. collections/time)?
> >>
> >>
> >>The reason to combine the two logics (size policies) isn't for
> >>particular applications. I don't get too surprised if you say it should
> >>be a separate size policy and leave the original adaptive size policy
> >>alone. My thinking is that users may want the same level of performance
> >>from the parallel collector (the adaptive size policy is enabled by
> >>default) unless a large part of the heap (> 70% by default) is free.
> >>This is my attempt to get the best of both. The flags are off by default
> >>since of course, not all applications need to have their heap shrunk
> >>this way.
> >>
> >>No, I don't have plots.
> >>
> >>Hiroshi
> >>
> >>
> >>
> >> Jon
> >>
> >> Hiroshi Yamauchi wrote On 03/10/10 15:17,:
> >>
> >> > Hi,
> >> >
> >> > I'd like to have this patch
> >> >
> >> > http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.00/<http://cr.openjdk.java.net/%7Erasbold/69XXXXX/webrev.00/>
> >> <http://cr.openjdk.java.net/%7Erasbold/69XXXXX/webrev.00/>
> >> > <http://cr.openjdk.java.net/%7Erasbold/69XXXXX/webrev.00/>
> >> >
> >> > contributed, if appropriate.
> >> >
> >> > It implements a simple heap shrinking logic based on the free
> ratio
> >> > (MaxHeapFreeRatio) in the parallel collector. The way it works is
> the
> >> > following: If the free ratio, (1.0 - <used> / <capacity>) * 100 >
> >> > MaxHeapFreeRatio, this logic kicks in. Otherwise, the (default)
> >> > adaptive size policy runs the show (as before). This feature is
> >> turned
> >> > off by default. There are two new flags to turn it on:
> >> >
> >> > UseFreeRatioForParallelGC - this enables it.
> >> > UseFreeRatioOnlyInSystemGCForParallelGC - this enables it only
> in
> >> > explicit System.gc() calls. This is more useful in apps that call
> >> > System.gc() when it's idle and don't want shrinking to happen at
> all
> >> > other times.
> >> >
> >> > In our tests, it appears to work well in a simple test and to help
> a
> >> > real app reduce its footprint (RSS) when it's idle.
> >> >
> >> > Thanks to Chuck Rasbold who uploaded the webrev on my behalf.
> >> >
> >> > Thanks,
> >> > Hiroshi
> >> >
> >>
> >>
> >>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20100318/8fb8aa44/attachment.htm>
More information about the hotspot-gc-dev
mailing list