<div dir="auto">Thanks Chris, Robbin,<div dir="auto"><br></div><div dir="auto">I'm waiting reviewer(s) for this change.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Yasumasa</div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017/09/19 午前7:14 "Chris Plummer" <<a href="mailto:chris.plummer@oracle.com">chris.plummer@oracle.com</a>>:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Yasumasa,<br>
<br>
Ok, I see now that CIntegerField is just an interface, so it's up to a class to implement getValue() to fetch the field. I'm a bit unclear on how that part works, but from responses by others, it seems this is ok.<br>
<br>
I've run all the tests I can find that use jstack or jhsdb, and the assert was not triggered. Probably need to have a NMethod on the stack to trigger the code you are fixing.<br>
<br>
thanks,<br>
<br>
Chris<div class="elided-text"><br>
<br>
On 9/17/17 1:13 AM, Yasumasa Suenaga wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Chris,<br>
<br>
I've tested this issue on Fedora 26 x86_64.<br>
I think we can sue CIntegerField at this point because CIntegerField is not specialized for various int size [1].<br>
In fact, CIntegerField had been used at this point [2], and HSDB worked fine.<br>
<br>
<br>
Thanks,<br>
<br>
Yasumasa<br>
<br>
<br>
[1] <a href="http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29" rel="noreferrer" target="_blank">http://hg.openjdk.java.net/jdk<wbr>10/master/file/fd36993f7bf5/<wbr>src/jdk.hotspot.agent/share/<wbr>classes/sun/jvm/hotspot/types/<wbr>CIntegerField.java#l29</a><br>
[2] <a href="http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3" rel="noreferrer" target="_blank">http://hg.openjdk.java.net/jdk<wbr>10/master/rev/cbfdbefc6ea3</a><br>
<br>
<br>
On 2017/09/17 3:58, Chris Plummer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Yasumasa,<br>
<br>
Is this on a 32-bit system? I don't see how you could otherwise call getCIntegerField() on a long type. jlong is always 64-bit and long is (generally) 32-bit on 32-bit systems, and 64-bit on 64-bit systems, at least that seems to be the case with linux.<br>
<br>
 From what I can see, _stack_traversal_mark is now the only long type in vmStructs.cpp. I don't know that we have a mechanism to safely fetch it on both 32-bit and 64-bit systems.<br>
<br>
_stack_traversal_mark seems to be a long because _traversals is also a long.<br>
<br>
     static long      _traversals;                   // Stack scan count, also sweep ID.<br>
<br>
This too might be considered a bug. I'm not sure why you would want the size of this field to vary between 32-bit and 64-bit systems (adding compiler-dev to help answer that).<br>
<br>
So, while I would agree that your fix is generally in the right direction, I think we first need to revisit the use of long for these fields. If they can be changed to an int, then your fix is correct (pending the changes to int). If not, then maybe we need getCLongField() support.<br>
<br>
And lastly, we really should have a test to detect this bug. Maybe we already do, and it is failing but is going unnoticed for some reason. I'll try to look into that some more on Monday.<br>
<br>
thanks,<br>
<br>
Chris<br>
<br>
On 9/16/17 5:20 AM, Yasumasa Suenaga wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
I tried to get thread dump via jstack command on CLHSDB. But it was failed as below:<br>
<br>
```<br>
Caused by: sun.jvm.hotspot.types.WrongTyp<wbr>eException: field "_stack_traversal_mark" in type nmethod is not of type jlong, but instead of type long<br>
        at jdk.hotspot.agent/sun.jvm.hots<wbr>pot.types.basic.BasicType.getF<wbr>ield(BasicType.java:206)<br>
        at jdk.hotspot.agent/sun.jvm.hots<wbr>pot.types.basic.BasicType.getF<wbr>ield(BasicType.java:212)<br>
        at jdk.hotspot.agent/sun.jvm.hots<wbr>pot.types.basic.BasicType.getJ<wbr>LongField(BasicType.java:249)<br>
        at jdk.hotspot.agent/sun.jvm.hots<wbr>pot.code.NMethod.initialize(<wbr>NMethod.java:108)<br>
        at jdk.hotspot.agent/sun.jvm.hots<wbr>pot.code.NMethod.access$000(<wbr>NMethod.java:35)<br>
        at jdk.hotspot.agent/sun.jvm.hots<wbr>pot.code.NMethod$1.update(NMet<wbr>hod.java:81) <br>
        at jdk.hotspot.agent/sun.jvm.hots<wbr>pot.runtime.VM.registerVMIniti<wbr>alizedObserver(VM.java:451)<br>
        at jdk.hotspot.agent/sun.jvm.hots<wbr>pot.code.NMethod.<clinit>(NMet<wbr>hod.java:79)<br>
        ... 23 more<br>
```<br>
<br>
I think this exception is caused by JDK-8186837.<br>
This changeset has changed the type of `nmethod::_stack_traversal_mar<wbr>k` to `long` from `jlong`.<br>
<br>
SA should follow this change.<br>
<br>
I uploaded a webrev for this issue. This webrev is generated from consolidated repo (jdk10/master).<br>
Could you review it?<br>
<br>
  <a href="http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~ys<wbr>uenaga/JDK-8187597/webrev.00/</a><br>
<br>
<br>
I cannot access JPRT. So I need reviewer.<br>
<br>
<br>
Thanks,<br>
<br>
Yasumasa<br>
<br>
</blockquote>
<br>
<br>
</blockquote></blockquote>
<br>
<br>
</div></blockquote></div><br></div>