<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">On 12/02/14 20:40, Jon Masamitsu wrote:<br>
</div>
<blockquote cite="mid:52FBCE32.2000708@oracle.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
<div class="moz-cite-prefix">On 2/12/2014 1:43 AM, Stefan Karlsson
wrote:<br>
</div>
<blockquote cite="mid:52FB4245.1030901@oracle.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Hi all,<br>
<br>
Please, review this patch to remove the do_code_roots parameter
from SharedHeap::process_strong_roots.<br>
<br>
The changes done are:<br>
- Change the code to rely on the ScannningOption so parameter
instead of do_code_roots.<br>
- Change GenMarkSweep and G1MarkSweep to adjust the code roots
with the help of process_strong_roots instead of doing it as a
separate phase after process_strong_roots.<br>
- Removed the unused
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
FalseClosure.<br>
<br>
After this patch the adjust phase of the GenMarkSweep and
G1MarkSweep will use the generic code in process_strong_roots,
which mark/claim the nmethods before they are processed. Before
the patch these two Serial Old GC adjust phases skipped the
mark/claim part. No noticeable Serial Old GC time increases were
found when this patch was performance tested.<br>
</blockquote>
<br>
Does this mean ("adjust phase ...") that the "mark/claim" does
not have any affect<br>
on later processing? Or actually does nothing (even though the
closures<br>
are applied)? <br>
</blockquote>
<br>
I think you answered this in your second mail.<br>
<br>
<blockquote cite="mid:52FBCE32.2000708@oracle.com" type="cite">
Which benchmarks did you use for performance testing?<br>
</blockquote>
<br>
I ran SPECjbb2005 and SPECjvm2008 compiler.compiler, with a low
tenuring threshold so that we promote more out to the old gen. The
benchmarks were run with and without -Xcomp and with heap size of 3G
and 256m. In the different combinations we had around 5000 - 10000
nmethods.<br>
<br>
The performance team ran WLS benchmarks and SPECjvm2008. They filled
the heap heap with a javaagent to make sure that we triggered old
GCs more often than we usually do. They also saw around 10000
nmethods in their runs.<br>
<br>
StefanK<br>
<br>
<blockquote cite="mid:52FBCE32.2000708@oracle.com" type="cite"> <br>
Jon<br>
<blockquote cite="mid:52FB4245.1030901@oracle.com" type="cite"> <br>
This cleanup is needed/wanted for G1 Class Unloading.<br>
<br>
Webrev:<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Estefank/8034761/webrev.00/">http://cr.openjdk.java.net/~stefank/8034761/webrev.00/</a><br>
<br>
RFE:<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8034761">https://bugs.openjdk.java.net/browse/JDK-8034761</a><br>
<br>
thanks,<br>
StefanK<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>