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