[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: RFR(M): 8039905: heapdump/OnOOMToFile and heapdump/OnOOMToPath fail with "assert(fr().interpreter_fr
From: Markus Grönlund <markus.gronlund () oracle ! com>
Date: 2014-06-25 11:58:17
Message-ID: 882452e7-0b02-414a-8a04-125737cb2faf () default
[Download RAW message or body]
Greetings,
Kindly looking for reviews for the following change:
Bug: http://bugs.openjdk.java.net/browse/JDK-8039905
Webrev: http://cr.openjdk.java.net/~mgronlun/8039905/webrev01/
Description:
JVMTI inspection code for following references makes use of a VM_HeapWalkOperation in \
order to follow-up root sets.
In bug:
https://bugs.openjdk.java.net/browse/JDK-8038624 - "interpretedVFrame::expressions() \
must respect InterpreterOopMap for liveness", it was found that the interpretedVFrame \
code had a discrepancy between basing length information from both asking the \
interpreter frame (which saw live expression slots for calls instructions) as well as \
the oop map (which did not).
The liveness decisions for a particular BCI should be based on what the oopmap gives, \
and that was done as of that bug (8038624).
In that process, I added an assert in an attempt to validate certain assumptions, and \
this assert has triggered during nightly testing in some cases.
I have therefore inspected the GC code which follow-up roots from an interpreted \
frame (please see frame::oops_interpreted_do() and \
InterpreterFrameClosure::do_offset() (in frame.cpp) for reference), and reworked \
InterpretedVFrame so that inspections for the locals and expression slots are done in \
the same way as the GC code (especially in regards to taking decisions on the \
InterpreterOopMap).
I needed to use InterpreterOopMap from a const context, and this is why I have \
"constified" this class where needed, as well as making "number_of_entries()" a const \
public accessor (to easily reach oop_mask length info).
Testing completed:
nsk/jdi* tests (especially the problematic ones reported for 8039905)
compiler/6507107/HeapWalkingTest
Thanks
Markus
[Attachment #3 (text/html)]
<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=iso-8859-1"><meta name=Generator content="Microsoft Word \
12 (filtered medium)"><style><!-- /* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 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:11.0pt;
font-family:"Calibri","sans-serif";}
h1
{mso-style-priority:9;
mso-style-link:"Heading 1 Char";
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:24.0pt;
font-family:"Times New Roman","serif";}
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;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.Heading1Char
{mso-style-name:"Heading 1 Char";
mso-style-priority:9;
mso-style-link:"Heading 1";
font-family:"Times New Roman","serif";
font-weight:bold;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 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 lang=SV link=blue vlink=purple><div \
class=WordSection1><p class=MsoNormal><span \
lang=EN-US>Greetings,<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>Kindly \
looking for reviews for the following change:<o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span \
lang=EN-US>Bug: <a href="http://bugs.openjdk.java.net/browse/JDK-8039905">http://bugs.openjdk.java.net/browse/JDK-8039905</a><o:p></o:p></span></p><p \
class=MsoNormal>Webrev: <a \
href="http://cr.openjdk.java.net/~mgronlun/8039905/webrev01/">http://cr.openjdk.java.net/~mgronlun/8039905/webrev01/</a> \
<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p \
class=MsoNormal>Description:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p \
class=MsoNormal><span lang=EN-US>JVMTI inspection code for following references makes \
use of a VM_HeapWalkOperation in order to follow-up root \
sets.<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>In \
bug:<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US><a \
href="https://bugs.openjdk.java.net/browse/JDK-8038624">https://bugs.openjdk.java.net/browse/JDK-8038624</a> \
- “</span><span lang=EN-US>interpretedVFrame::expressions() must respect \
InterpreterOopMap for liveness”, it was found that the interpretedVFrame code \
had a discrepancy between basing length information from both asking the interpreter \
frame (which saw live expression slots for calls instructions) as well as the oop map \
(which did not). <o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US>The \
liveness decisions for a particular BCI should be based on what the oopmap gives, and \
that was done as of that bug (8038624). <o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span \
lang=EN-US>In that process, I added an assert in an attempt to validate certain \
assumptions, and this assert has triggered during nightly testing in some cases. \
<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal \
style='text-autospace:none'><span lang=EN-US>I have therefore inspected the GC code \
which follow-up roots from an interpreted frame (please see </span><span \
lang=EN-US>frame::oops_interpreted_do() and </span><span \
lang=EN-US>InterpreterFrameClosure::do_offset() (in frame.cpp) for reference), and \
reworked InterpretedVFrame so that inspections for the locals and expression slots \
are done in the same way as the GC code (especially in regards to taking decisions on \
the InterpreterOopMap).<o:p></o:p></span></p><p class=MsoNormal \
style='text-autospace:none'><span lang=EN-US><o:p> </o:p></span></p><p \
class=MsoNormal style='text-autospace:none'><span lang=EN-US>I needed to use \
InterpreterOopMap from a const context, and this is why I have \
“constified” this class where needed, as well as making \
“number_of_entries()” a const public accessor (to easily reach oop_mask \
length info).<o:p></o:p></span></p><p class=MsoNormal \
style='text-autospace:none'><span lang=EN-US><o:p> </o:p></span></p><p \
class=MsoNormal style='text-autospace:none'><span lang=EN-US>Testing \
completed:<o:p></o:p></span></p><p class=MsoNormal style='text-autospace:none'><span \
lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal \
style='text-autospace:none'><span lang=EN-US>nsk/jdi* tests (especially the \
problematic ones reported for 8039905)<o:p></o:p></span></p><p class=MsoNormal \
style='text-autospace:none'><span \
lang=EN-US>compiler/6507107/HeapWalkingTest<o:p></o:p></span></p><p \
class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span \
lang=EN-US>Thanks<o:p></o:p></span></p><p class=MsoNormal><span \
lang=EN-US>Markus<o:p></o:p></span></p></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic