<div>Looks good to me.</div><div><br></div><div><div>igor</div><div><br></div></div>
                 
                <p style="color: #A0A0A8;">On Monday, March 19, 2012 at 10:54 AM, John Cuthbertson wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div><div>Hi Everyone,</div><div><br></div><div>Can I have a couple of volunteers review the changes for this CR? The </div><div>webrev can be found at: <a href="http://cr.openjdk.java.net/~johnc/7143511/webrev.0/">http://cr.openjdk.java.net/~johnc/7143511/webrev.0/</a>.</div><div><br></div><div>I am cc'ing the compiler-dev list as I changed the nmethod class to make </div><div>the routine nmethod::test_oops_do_mark() available in non-debug builds.</div><div><br></div><div>Summary:</div><div>While running SPECjbb2012, it was noticed that the GC Worker Other time </div><div>(printed as part of the PrintGCDetails output) was quite high on certain </div><div>platforms. An investigation discovered that this time was coming from </div><div>the StrongRootsScope destructor (which is executed by the VM thread and </div><div>was being incorrectly attributed as part of the parallel time). Most of </div><div>the time for the StrongRootsScope destructor was coming from walking the </div><div>marked nmethods list, where the nmethods discovered by the </div><div>CodeBlobToOops closure in SharedHeap::process_strong_roots() are walked </div><div>to fix up any oops that may have moved during the GC. Further </div><div>investigation revealed that the nmethods were being added to the marked </div><div>list unconditionally. With TieredCompilation, the number of nmethods in </div><div>the code cache (and the number of oops in each nmethod) significanly </div><div>increased (~6000 vs. ~700 nmethods and ~115K vs ~15K oops) increasing </div><div>the time it took to walk the marked nmethod list. It was also observed </div><div>that most of the nmethods on the marked list did not contain any </div><div>pointers into the collection set and so the oops that they were pointing </div><div>to did not move during the GC. The solution was to limit the number of </div><div>nmethods placed on to the marked list by specializing the </div><div>CodeBlobToOopClosure to filter out those nmethods that did not point </div><div>into the collection set.</div><div><br></div><div>The other changes include refactoring the code in G1ParTask:work() and </div><div>where the G1ParTask is executed in evacuate_collection_set() so that the </div><div>values printed for the GC Worker Other time and (the new) Code Root </div><div>Fixup time are accurately calculated.</div><div><br></div><div>Testing: SPECjbb2012 on several platforms; the GC test suite with heap </div><div>verification after GC enabled.</div><div><br></div><div>Thanks,</div><div><br></div><div>JohnC</div></div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div>
                    <br>
                </div>