<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hello Coleen, Kim,<br>
<br>
Thanks for your review! I moved ensure_klass_alive() to
jvmtiGetLoadedClasses.cpp. Please take a look at the following
webrev:<br>
<br>
<a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~poonam/8187577/webrev.01/">http://cr.openjdk.java.net/~poonam/8187577/webrev.01/</a><br>
<br>
Thanks,<br>
Poonam<br>
<br>
<div class="moz-cite-prefix">On 2/6/2018 3:23 PM,
<a class="moz-txt-link-abbreviated" href="mailto:coleen.phillimore@oracle.com">coleen.phillimore@oracle.com</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e3f72c76-1ead-81e8-e753-7fb6fe68a599@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<br>
Hi Poonam,<br>
<br>
Kim and I discussed this fix and we think it's correct for this
case, but can you move ensure_klass_alive out of Klass and into a
local static function in jvmtiGetLoadedClasses.cpp? We don't
want this to be the normal way to do things in jdk11 but there are
similar local functions in jdk10 and 8 for your backports, so this
would be like those ones.<br>
<br>
Long term, Kim convinced me that Stefan is right and we have to
use the AccessAPI to keep alive class loaders (or holders) when
classes and other things are iterated through the
ClassLoaderDataGraph. I'll make this change at some point soon
when I do some other ClassLoaderDataGraph changes.<br>
<br>
Thanks,<br>
Coleen<br>
<br>
<div class="moz-cite-prefix">On 2/2/18 4:22 PM, Poonam Parhar
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1f8db89b-f411-c508-7858-e565e1977eb3@oracle.com">
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
<p>Adding Coleen to this RFR.<br>
</p>
On 2/2/2018 11:41 AM, Poonam Parhar wrote:<br>
<blockquote type="cite"
cite="mid:28c2bbe9-13c2-7b19-4347-991905d34d62@oracle.com">
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
Hello,<br>
<br>
Please review this fix for a G1GC crash occurring during
concurrent marking.<br>
<br>
Bug: <a class="issue-link" data-issue-key="JDK-8187577"
href="https://bugs.openjdk.java.net/browse/JDK-8187577"
id="key-val" rel="4939883" moz-do-not-send="true">JDK-8187577:</a>
JVM crash during gc doing concurrent marking<br>
Webrev: <a class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Epoonam/8187577/webrev.00/"
moz-do-not-send="true">http://cr.openjdk.java.net/~poonam/8187577/webrev.00/</a><br>
<br>
Problem:<br>
A klass that has been considered unreachable by G1, can be
looked up in the CLD/SD, and its _java_mirror or _class_loader
can be stored in a root or any other reachable object making
it alive again. Whenever a klass is resurrected in this
manner, the SATB part of G1 needs to be notified about this,
otherwise the concurrent marking remark phase will wrongly
unload that klass.<br>
<br>
In this particular crash, while a G1 is doing concurrent
marking and has prepared its list of unreachable classes,
JVMTI on a Java thread traverses classes in the CLD and stores
thread-local JNIHandles for the java_mirror of the loaded
classes. G1 does not have knowledge of these thread-local
JNIHandles, and in the remark phase it unloads classes as per
its prior knowledge of unreachable classes. But when these
JNIHandles are later scanned, it leads to a crash.<br>
<br>
Solution:<br>
Inform G1's SATB that a klass has been resurrected and it
should not be unloaded.<br>
<br>
Testing:<br>
- Customer verification testing<br>
- mach5 jdk-tier1-3, hs-tier1-2<br>
<br>
Thanks,<br>
Poonam<br>
<br>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>