<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hiroshi,<br>
<br>
In parallelScavengeHeap.cpp<br>
<br>
In the UseParallelGC collector the initial size (init_size) can be<br>
significantly larger than the minimum size. If you want to shrink down<br>
the heap to minimize footprint, do you really want to limit by the<br>
initial size instead of the minimum size?<br>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<pre><span class="new">1001 maximum_desired_capacity = MAX2(maximum_desired_capacity, init_size);
Similarly here the amount of used data could be very small and
setting the floor at the initial size may not be what you
want.
</span></pre>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<pre><span class="new">1034 minimum_desired_capacity = MAX2(minimum_desired_capacity, init_size);</span></pre>
In psYoungGen.cpp you guard output with PrintGC only. In similar<br>
cases this type of output is guarded with Verbose also. Does this<br>
output as is get printed in the middle of the usual<br>
-verbosegc (also known as PrintGC) line?<br>
<br>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<pre><span class="new">1000 if (PrintGC) {</span>
<span class="new">1001 gclog_or_tty->print_cr(" Resizing young gen. expand_bytes=%d,%d",</span>
<span class="new">1002 eden_expand_bytes, survivor_expand_bytes);</span>
<span class="new">1003 gclog_or_tty->print("BEFORE: Young Gen: ");</span>
<span class="new">1004 gclog_or_tty->print("eden capacity : " SIZE_FORMAT ", ",</span>
<span class="new">1005 eden_space()->capacity_in_bytes());</span>
<span class="new">1006 gclog_or_tty->print("eden used : " SIZE_FORMAT ", " ,</span>
<span class="new">1007 eden_space()->used_in_bytes());</span>
<span class="new">1008 gclog_or_tty->print("survivor capacity : " SIZE_FORMAT ", ",</span>
<span class="new">1009 from_space()->capacity_in_bytes());</span>
<span class="new">1010 gclog_or_tty->print_cr("survivor used : " SIZE_FORMAT ", " ,</span>
<span class="new">1011 from_space()->used_in_bytes());</span>
<span class="new">1012 }</span>
In psOldGen.cpp you could try to expand up to max_gen_size
instead of returning?
501 void PSOldGen::try_to_expand_by(size_t expand_bytes) {
502 if (expand_bytes < MinHeapDeltaBytes ||
503 capacity_in_bytes() + expand_bytes > max_gen_size()) {
504 return;
</pre>
Additionally PSOldGen::expand() chooses to use MinHeapDeltaBytes<br>
as the minimum expansion size (in the sense that sizes for expansion<br>
are round up to MinHeapDeltaBytes). You would rather not expand<br>
for less than MinHeapDeltaBytes? I'll admit that there maybe some<br>
inconsistencies in the way MinHeapDeltaBytes is used. Just checking<br>
that this is what you want to do.<br>
<br>
Again, seems to me that you want to shrink down to the minimum<br>
generation size as opposed to the initial size.<br>
<br>
523 void PSOldGen::try_to_shrink_by(size_t shrink_bytes) {<br>
524 if (shrink_bytes < MinHeapDeltaBytes ||<br>
525 capacity_in_bytes() - shrink_bytes < init_gen_size()) {<br>
526 return;<br>
527 }<br>
<br>
In globals.hpp. We may want this feature implemented in other <br>
collectors at some point - G1 comes to mind. I'd drop the leading<br>
PS on the flag so that it is ResizeByFreeRatioWithSystemGC.<br>
<br>
3079 product(bool, PSResizeByFreeRatioWithSystemGC,
false, \<br>
3080 "Resize the heap by free ratio in System.gc()
" \<br>
3081 "under UseParallelGC") <br>
<br>
<br>
The rest looks fine.<br>
<br>
Jon <br>
<br>
On 4/29/10 2:48 PM, Hiroshi Yamauchi wrote:
<blockquote
cite="mid:i2nd6262f011004291448m640d4fb2x818fcd6c97a2e0c9@mail.gmail.com"
type="cite">
<pre wrap="">OK. No problem.
On Thu, Apr 29, 2010 at 1:58 PM, Jon Masamitsu <a
class="moz-txt-link-rfc2396E" href="mailto:jon.masamitsu@oracle.com"><jon.masamitsu@oracle.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hiroshi,
These changes are what I was expecting after
we had talked. I still have to look at the details but may not
get to those for a couple of days.
Jon
On 04/28/10 13:37, Hiroshi Yamauchi wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Jon,
Here's an update based on what we discussed:
<a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Erasbold/69XXXXX/webrev.02/">http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.02/</a>
The summary of the latest changes is that
1. On minor collections, the free ratio is computed based on the young
gen heap, rather than both the young gen and the old gen heaps.
2. When -XX:-UseAdaptiveSizePolicy, the free ratio based resizing
happens on normal collections, rather than just on System.gc() when
-XX:+PSResizeByFreeRatioWithSystemGC.
Hiroshi
On Tue, Apr 13, 2010 at 11:21 AM, Hiroshi Yamauchi <a
class="moz-txt-link-rfc2396E" href="mailto:yamauchi@google.com"><yamauchi@google.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Jon,
I finally got to this. Here's the webrev for a second version based on
our discussion (thanks to Chuck Rasbold):
<a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Erasbold/69XXXXX/webrev.01/">http://cr.openjdk.java.net/~rasbold/69XXXXX/webrev.01/</a>
The summary of change is that the logic for expansion based on
MinHeapFreeRatio was added and only the flag for the System.gc was
retained (and renamed to PSResizeByFreeRatioWithSystemGC.)
Thanks,
Hiroshi
On Thu, Apr 1, 2010 at 9:02 AM, Jon Masamitsu <a
class="moz-txt-link-rfc2396E" href="mailto:jon.masamitsu@oracle.com"><jon.masamitsu@oracle.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 03/31/10 11:26, Hiroshi Yamauchi wrote:
</pre>
<blockquote type="cite">
<pre wrap="">...
I think we agree that it's a good idea to try to shrink the heap in
response to System.gc() in such a scenario/app.
</pre>
</blockquote>
<pre wrap="">Yes on the shrinking on a System.gc() and perhaps for symmetry also
expanding
a small heap to MinFreeHeapRatio? UseAdaptiveSizePolicy will shrink the
heap
down during periods of low activity and it might be useful to swiftly
expand
the
heap on a System.gc().
</pre>
<blockquote type="cite">
<pre wrap="">Since we are talking about a setting where the free ratio flags takes
precedence over the psAdaptiveSizePolicy's throughput goals, the
suggested
logic in the original webrev is perhaps not so terrible? If so, I
suppose
the logic for UseFreeRatioOnlyInSystemGCForParallelGC does help with
that
because it can shrink the heap regardless of the throughput goal. It
may
make sense to remove UseFreeRatioForParallelGC and keep
UseFreeRatioOnlyInSystemGCForParallelGC only. If you'd like to see it
happen
inside psAdaptiveSizePolicy instead, the current webrev does not work.
</pre>
</blockquote>
<pre wrap="">I like the structure of the original webrev with regard to the logic for
using FreeRation. It's simpler than embedding it in the
PSAdaptivesizePolicy.
243 if (UseFreeRatioOnlyInSystemGCForParallelGC &&
245 gc_cause == GCCause::_java_lang_system_gc)) {
compute_new_size(); <<<<<<<< generalization of
<<<<<<<< try_to_shrink_by_free_ratio()
248 } else {
use current UseAdaptiveSizePolicy
}
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>