<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><br>
      Hi all,<br>
      <br>
      I haven't commented in this email thread but I've been following
      the discussion with interest. Since I was the one who brought up
      the question around the 4GB limit, I'd just like to state that I
      agree with the decision to skip this limit.<br>
      <br>
      Thanks,<br>
      Bengt<br>
      <br>
      <br>
      On 1/15/13 8:20 PM, Charlie Hunt wrote:<br>
    </div>
    <blockquote
      cite="mid:FDA61CAB-EFDA-474A-B052-867251049216@salesforce.com"
      type="cite">Avg Response Time ... (sigh) --- one of our favorite
      subjects.  ;-)
      <div><br>
        <div>You're right, if the marking cycles start earlier than
          ideally desired, you end up under-utilizing heap space and
          potentially having to tame mixed GCs.  But, G1 has a tunable
          we can set to start the marking cycle later.  The challenge
          there is setting the initiating heap occupancy percent too
          high and losing the race.  But, by setting it higher (and
          avoiding losing the race) with larger  heaps hopefully
          translates to more "good candidate" old gen regions to collect
          and also hopefully makes the exercise of taming mixed GCs a
          little easier too.</div>
        <div><br>
        </div>
        <div>Thanks for sharing your thoughts.</div>
        <div><br>
        </div>
        <div>charlie ...</div>
        <div><br>
          <div>
            <div>On Jan 15, 2013, at 12:45 PM, Monica Beckwith wrote:</div>
            <br class="Apple-interchange-newline">
            <blockquote type="cite">
              <meta content="text/html; charset=ISO-8859-1"
                http-equiv="Content-Type">
              <div bgcolor="#FFFFFF" text="#000000"> Thanks, Charlie - <br>
                <br>
                If I may add two more things to John's points below and
                also expand a bit on the "latency" comment - <br>
                Even though we talk about latency, in reality, I have
                seen many people with bigger heap (around 200Gs)
                requirements really concerned about ART (Average
                Response Time)/ Throughput.<br>
                Also, we should remember that if the marking cycle is
                triggered earlier and more often, then we may end up
                under-utilizing the bigger heaps and will definitely
                have to spend time "taming the mixedGCs" :)<br>
                <br>
                just my 2 cents.<br>
                <br>
                -Monica<br>
                <br>
                On 1/15/2013 12:01 PM, Charlie Hunt wrote:
                <blockquote
                  cite="mid:7D0DFCF4-4F58-4902-BDC0-E1868BB5D786@salesforce.com"
                  type="cite">
                  <pre wrap="">Hi John,

Completely agree with the excellent points you mention below (thanks for being thorough and listing them!).

Given G1 is (somewhat) positioned as a collector to use when improved latency is an important criteria, I think the tradeoffs are something people are willing to live with too.

Fwiw, you have my "ok" to go ahead with your suggestion to apply the new young gen bounds to all heap sizes.

hths,

charlie ...

On Jan 15, 2013, at 11:40 AM, John Cuthbertson wrote:

</pre>
                  <blockquote type="cite">
                    <pre wrap="">Hi Charlie

Thanks for looking over the changes. Replies inline....


On 1/11/2013 11:32 AM, Charlie Hunt wrote:
</pre>
                    <blockquote type="cite">
                      <pre wrap="">Hi John,

Fwiw, I'm fine with Bengt's suggestion of having G1NewSizePercent the same for all Java heap sizes.
</pre>
                    </blockquote>
                    <pre wrap="">I don't have a problem with this. By applying it heaps > 4GB , I was 
just being conservative.

</pre>
                    <blockquote type="cite">
                      <pre wrap="">I'm on the fence with whether to do the same with G1MaxNewSizePercent.  For me I find the MaxNewSizePercent a bit tricky than NewSizePercent.  WIth NewSizePercent, if young gen is sized "too small", I think the worst case is we have some GCs that are well below the pause time target.  But, with MaxNewSizePercent, if it's allowed to get "too big", then the worst case is evacuation failures.

So, if you did move MaxNewSizePercent down to 60, we'd have a situation where we'd be less likely to have evacuation failures.  Perhaps it's ok to apply this change to all Java heap sizes too?
</pre>
                    </blockquote>
                    <pre wrap="">Again I don't have a problem with applying the new value to all heap 
sizes but I am a little concerned about the implications. The benefit is 
definitely less risk of evacuation failures but the it could also

* increase the number of young GCs:
    ** increasing the GC overhead and increasing the heap slightly more 
aggressively
    ** lowering throughput
* slightly increase the amount that gets promoted
    ** triggering marking cycles earlier and more often (increased SATB 
barrier overhead)
    ** more cards to be refined (we only refine cards in old regions) 
increasing the write barrier costs and the RS updating phase of the pauses,
    ** increases the importance of "taming the mixed GCs".

>From Kirk's email it sounds like this is a trade off people are 
prepared to live with.

Unless I hear any objections, I'll apply the new young gen bounds to all 
heap sizes.

JohnC
</pre>
                  </blockquote>
                </blockquote>
                <br>
                <div class="moz-signature">-- <br>
                  <a moz-do-not-send="true"
                    href="http://www.oracle.com/" target="_blank"><span><oracle_sig_logo.gif></span></a><br>
                  <font color="#666666" face="Verdana, Arial, Helvetica,
                    sans-serif" size="2">Monica Beckwith | Java
                    Performance Engineer<br>
                    VOIP: <a href="tel:+1%20512%20401%201274"
                      moz-do-not-send="true">+1 512 401 1274</a> <br>
                    Texas </font> <br>
                  <a moz-do-not-send="true"
                    href="http://www.oracle.com/commitment"
                    target="_blank"><span><green-for-email-sig_0.gif></span></a>
                  <font color="#4B7D42" face="Verdana, Arial, Helvetica,
                    sans-serif" size="1">Oracle is committed to
                    developing practices and products that help protect
                    the environment</font>
                  <!-- This signature was generated by the MyDesktop Oracle Business Signature utility version 3.9 -->
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>