<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas","serif";
color:black;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor="white" lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Hello Jon,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">CMS: You’ve recognized the patch as a correct fix and kindly proposed to sponsor it. Please see my first email or
</span><a href="https://bugs.openjdk.java.net/browse/JDK-8135318">https://bugs.openjdk.java.net/browse/JDK-8135318</a>
<span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">for the patch.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">ParallelOld: I had some suspects but you’ve explained the code so there is no need to patch anything.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thank you in advance,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Ivan
<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext">From:</span></b><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext"> Jon Masamitsu [mailto:jon.masamitsu@oracle.com]
<br>
<b>Sent:</b> Montag, 2. November 2015 23:30<br>
<b>To:</b> Volker Simonis; Galkin, Ivan<br>
<b>Cc:</b> hotspot-gc-dev@openjdk.java.net<br>
<b>Subject:</b> Re: CMS: wrong max_eden_size for check_gc_overhead_limit<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Volker and Ivan,<br>
<br>
Sorry for dropping the ball on this. There was a patch for CMS.<br>
There was also some discussion about ParallelGC and a patch<br>
but that ParallelGC patch should not be pushed, right?<br>
<br>
Jon<br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">On 10/26/2015 07:17 AM, Volker Simonis wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>Hi Jon, Ivan,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>what's the status of this bug?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Are there still any changes required?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>@Jon: as far as I understood, you wanted to sponsor this fix. Are<o:p></o:p></pre>
<pre>there still any changes required from your side?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Thank you and best regards,<o:p></o:p></pre>
<pre>Volker<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>On Mon, Sep 14, 2015 at 7:41 PM, Galkin, Ivan <a href="mailto:ivan.galkin@sap.com"><ivan.galkin@sap.com></a> wrote:<o:p></o:p></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>Hello Jon,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>thank you for the explanation. I was worried about the possible underflow of<o:p></o:p></pre>
<pre>the following subtraction:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre> size_t max_eden_size = max_young_size -<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> young_gen->from_space()->capacity_in_bytes() -<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> young_gen->to_space()->capacity_in_bytes();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Is it correct that max_young_size >= young_gen->max_size() is always true?<o:p></o:p></pre>
<pre>(requires that old_gen can grow, but cannot shrink)<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Otherwise there is a chance of underflow if SurvivorRatio==1.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Best regards,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Ivan<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>From: Jon Masamitsu [<a href="mailto:jon.masamitsu@oracle.com">mailto:jon.masamitsu@oracle.com</a>]<o:p></o:p></pre>
<pre>Sent: Freitag, 11. September 2015 18:58<o:p></o:p></pre>
<pre>To: Galkin, Ivan<o:p></o:p></pre>
<pre>Cc: <a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.net</a><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Subject: Re: CMS: wrong max_eden_size for check_gc_overhead_limit<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>On 9/10/2015 3:54 AM, Galkin, Ivan wrote:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Hello Jon,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>thank you for your review and your support.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Besides CMS the function check_gc_overhead_limit() is called only in<o:p></o:p></pre>
<pre>PSMarkSweep, PSParallelCompact and PSScavenge:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>* PSMarkSweep, PSParallelCompact use the formula “young_gen->max_size() -<o:p></o:p></pre>
<pre>young_gen->from_space()->capacity_in_bytes() -<o:p></o:p></pre>
<pre>young_gen->to_space()->capacity_in_bytes()”, which is correct because<o:p></o:p></pre>
<pre>PSYoungGen::max_size() == “size in bytes reserved for young generation”<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>* PSScavenge use a similar calculation, however both max_young_size and<o:p></o:p></pre>
<pre>survivor_limit are recalculated because of MinHeapFreeRation &<o:p></o:p></pre>
<pre>MaxHeapFreeRatio<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>// START SNIPPET FROM PSScavenge::invoke_no_policy(), see<o:p></o:p></pre>
<pre>hotspot/src/share/vm/gc/parallel/psScavenge.cpp<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> size_t max_young_size = young_gen->max_size();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> ...<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> if (MinHeapFreeRatio != 0 || MaxHeapFreeRatio != 100) {<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> max_young_size = MIN2(old_gen->capacity_in_bytes() / NewRatio,<o:p></o:p></pre>
<pre>young_gen->max_size());<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> }<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> ...<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> size_t survivor_limit =<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> size_policy->max_survivor_size(max_young_size);<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> ...<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> assert(young_gen->max_size() ><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> young_gen->from_space()->capacity_in_bytes() +<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> young_gen->to_space()->capacity_in_bytes(),<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> "Sizes of space in young gen are out-of-bounds");<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>This is a bit curious although the way the survivor spaces<o:p></o:p></pre>
<pre>grow and shrink with ParallelGC, I can imagine that it is<o:p></o:p></pre>
<pre>there to catch really bad calculations of the survivor<o:p></o:p></pre>
<pre>sizes. If the survivors grow larger than the current<o:p></o:p></pre>
<pre>eden size, it is not necessarily a bug, it's just not<o:p></o:p></pre>
<pre>useful (part of the survivor space would just never<o:p></o:p></pre>
<pre>be used). It's a fuzzy assertion but a safe one.<o:p></o:p></pre>
<pre>See my comment below on your alternative.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> ...<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> size_t max_eden_size = max_young_size -<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> young_gen->from_space()->capacity_in_bytes() -<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> young_gen->to_space()->capacity_in_bytes();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>The survivor spaces can grow small (in principle down to<o:p></o:p></pre>
<pre>1 page) so I don't think survivor limit (which is their maximum<o:p></o:p></pre>
<pre>size relative to some young gen size) would give a maximum<o:p></o:p></pre>
<pre>eden size.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>// END SNIPPET FROM PSScavenge::invoke_no_policy()<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I’m not ably to say if there is an error in the calculation of<o:p></o:p></pre>
<pre>max_eden_size, however I’m wondering a) why recalculated survivor_limit is<o:p></o:p></pre>
<pre>not used and b) what is the marked assertion good for?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>In my opinion the calculation should look as following. I didn’t test the<o:p></o:p></pre>
<pre>change. It’s only deduced, so every comment would be welcome.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>diff -r f74b3ce62e1f src/share/vm/gc/parallel/psScavenge.cpp<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>--- a/src/share/vm/gc/parallel/psScavenge.cpp Fri Sep 04 17:33:56 2015 -0700<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>+++ b/src/share/vm/gc/parallel/psScavenge.cpp Thu Sep 10<o:p></o:p></pre>
<pre>12:30:19 2015 +0200<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>@@ -560,18 +560,14 @@<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> if (UseAdaptiveGenerationSizePolicyAtMinorCollection &&<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> (AdaptiveSizePolicy::should_update_eden_stats(gc_cause))) {<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> // Calculate optimal free space amounts<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>- assert(young_gen->max_size() ><o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>- young_gen->from_space()->capacity_in_bytes() +<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>- young_gen->to_space()->capacity_in_bytes(),<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>+ assert(max_young_size > 2 * survivor_limit,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>survivor_limit is calculated based on max_young_size<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>535 size_t survivor_limit =<o:p></o:p></pre>
<pre>536 size_policy->max_survivor_size(max_young_size);<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>so "max_young_size > 2*survivor_limit" shouldn't fail<o:p></o:p></pre>
<pre>unless MinSurvivorRatio is broken. Do you agree?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I'd be willing to delete the assertion if you like.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Jon<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre> "Sizes of space in young gen are out-of-bounds");<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> size_t young_live = young_gen->used_in_bytes();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> size_t eden_live = young_gen->eden_space()->used_in_bytes();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> size_t cur_eden = young_gen->eden_space()->capacity_in_bytes();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> size_t max_old_gen_size = old_gen->max_gen_size();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>- size_t max_eden_size = max_young_size -<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>- young_gen->from_space()->capacity_in_bytes() -<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>- young_gen->to_space()->capacity_in_bytes();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>+ size_t max_eden_size = max_young_size - 2 * survivor_limit;<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> // Used for diagnostics<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> size_policy->clear_generation_free_space_flags();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Best regard,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Ivan<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>P.S. Your questions about contributor agreement and a bug report were<o:p></o:p></pre>
<pre>answered by my colleague Volker Simonis<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>From: hotspot-gc-dev [<a href="mailto:hotspot-gc-dev-bounces@openjdk.java.net">mailto:hotspot-gc-dev-bounces@openjdk.java.net</a>] On<o:p></o:p></pre>
<pre>Behalf Of Jon Masamitsu<o:p></o:p></pre>
<pre>Sent: Mittwoch, 9. September 2015 18:22<o:p></o:p></pre>
<pre>To: <a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.net</a><o:p></o:p></pre>
<pre>Subject: Re: CMS: wrong max_eden_size for check_gc_overhead_limit<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Ivan,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>You're correct about this bug.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Is it correct that you're covered by the SAP contributor<o:p></o:p></pre>
<pre>agreement?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Have you filed a bug report on this?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Have you checked the other GC's for this problem?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I can sponsor this fix.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Thanks.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Jon<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>On 9/8/2015 2:21 AM, Galkin, Ivan wrote:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Hello all,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I believe the calculation of max_eden_size which is needed to check the GC<o:p></o:p></pre>
<pre>overhead in CMS is incorrect. Namely in concurrentMarkSweepGeneration.cpp<o:p></o:p></pre>
<pre>the following expression is used:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>size_t max_eden_size = _young_gen->max_capacity() -<o:p></o:p></pre>
<pre>_young_gen->to()->capacity() - _young_gen->from()->capacity();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>According to the implementation of DefNewGeneration::max_capacity() the<o:p></o:p></pre>
<pre>expression can be unfolded as:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre> size_t max_eden_size = (“reserved size of young gen” – “size<o:p></o:p></pre>
<pre>of survivor space”) – “size of survivor space” – “size of survivor space”;<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>So the value becomes too small (survival spaces are accounted 3 times!),<o:p></o:p></pre>
<pre>which can lead to the following problems:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>1. max_eden_size is too small and GC overhead is wrongfully recognized<o:p></o:p></pre>
<pre>too early<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>2. max_eden_size == 0 (all young spaces have the same size;<o:p></o:p></pre>
<pre>-XX:SurvivorRatio=1) and GC overhead is never happens (see implementation of<o:p></o:p></pre>
<pre>AdaptiveSizePolicy::check_gc_overhead_limit:<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>a. max_eden_size == 0 leads to mem_free_eden_limit == 0;<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>b. free_in_eden < mem_free_eden_limit is always false, since both are<o:p></o:p></pre>
<pre>unsigned integers and mem_free_eden_limit is 0)<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>I would therefore suggest the following fix (DefNewGeneration::<o:p></o:p></pre>
<pre>max_eden_size() already contains the correctly calculated capacity of eden):<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>diff -r f74b3ce62e1f src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>--- a/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Fri Sep<o:p></o:p></pre>
<pre>04 17:33:56 2015 -0700<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>+++ b/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp Mon Sep 07<o:p></o:p></pre>
<pre>18:08:39 2015 +0200<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>@@ -1563,9 +1563,7 @@<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> do_compaction_work(clear_all_soft_refs);<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre> // Has the GC time limit been exceeded?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>- size_t max_eden_size = _young_gen->max_capacity() -<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>- _young_gen->to()->capacity() -<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>- _young_gen->from()->capacity();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>+ size_t max_eden_size = _young_gen->max_eden_size();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> GCCause::Cause gc_cause = gch->gc_cause();<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> size_policy()->check_gc_overhead_limit(_young_gen->used(),<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> _young_gen->eden()->used(),<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Could anybody please review and sponsor the change?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Thank you in advance,<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Ivan<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
</blockquote>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>