RFR: JDK-8187597: WrongTypeException is occurred at CLHSDB jstack after JDK-8186837

[Chris Plummer]

On 9/18/17 6:14 AM, Robbin Ehn wrote:
> Hi,
>
> FYI: It's been long since duke:
>
>    0:   nonstatic_field(nmethod, _stack_traversal_mark, 
> long)                                  \
>
> It's now also volatile.
>
> The correct type should/could probably be some like 
> (u)int_fast32_t/intx or whatever.
>
> If there is an issue with variable length types in vmStructs we have 
> had that issue for very long AFAICT.
Hi Robbin,

I was more concerned with it being variable in general between 32-bit 
and 64-bit platforms, not that it was an issue for vmStructs. This does 
not seem like the type of value that would need to be a different size 
depending on the bitness, so it should be made whichever smallest size 
that is big enough. As you point out, something like intx, although the 
data structure it is in is full of ints, so probably int would be 
sufficient.

thanks,

Chris
>
> But looking at error message below:
> field "_stack_traversal_mark" in type nmethod is not of type jlong, 
> but instead of type long
>
> It was jlong for about a month until I reverted that change (back to 
> long but volatile).
> So it looks like you are running tools from an older build with a 
> newer vm or something like that ?
>
> /Robbin
>
> On 09/17/2017 10:13 AM, Yasumasa Suenaga wrote:
>> Hi Chris,
>>
>> I've tested this issue on Fedora 26 x86_64.
>> I think we can sue CIntegerField at this point because CIntegerField 
>> is not specialized for various int size [1].
>> In fact, CIntegerField had been used at this point [2], and HSDB 
>> worked fine.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> [1] 
>> http://hg.openjdk.java.net/jdk10/master/file/fd36993f7bf5/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/CIntegerField.java#l29
>> [2] http://hg.openjdk.java.net/jdk10/master/rev/cbfdbefc6ea3
>>
>>
>> On 2017/09/17 3:58, Chris Plummer wrote:
>>> Hi Yasumasa,
>>>
>>> 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.
>>>
>>>  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.
>>>
>>> _stack_traversal_mark seems to be a long because _traversals is also 
>>> a long.
>>>
>>>      static long      _traversals;                   // Stack scan 
>>> count, also sweep ID.
>>>
>>> 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).
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>> On 9/16/17 5:20 AM, Yasumasa Suenaga wrote:
>>>> Hi all,
>>>>
>>>> I tried to get thread dump via jstack command on CLHSDB. But it was 
>>>> failed as below:
>>>>
>>>> ```
>>>> Caused by: sun.jvm.hotspot.types.WrongTypeException: field 
>>>> "_stack_traversal_mark" in type nmethod is not of type jlong, but 
>>>> instead of type long
>>>>         at 
>>>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:206)
>>>>         at 
>>>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getField(BasicType.java:212)
>>>>         at 
>>>> jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicType.getJLongField(BasicType.java:249)
>>>>         at 
>>>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.initialize(NMethod.java:108)
>>>>         at 
>>>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.access$000(NMethod.java:35)
>>>>         at 
>>>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod$1.update(NMethod.java:81) 
>>>>
>>>>         at 
>>>> jdk.hotspot.agent/sun.jvm.hotspot.runtime.VM.registerVMInitializedObserver(VM.java:451)
>>>>         at 
>>>> jdk.hotspot.agent/sun.jvm.hotspot.code.NMethod.<clinit>(NMethod.java:79)
>>>>         ... 23 more
>>>> ```
>>>>
>>>> I think this exception is caused by JDK-8186837.
>>>> This changeset has changed the type of 
>>>> `nmethod::_stack_traversal_mark` to `long` from `jlong`.
>>>>
>>>> SA should follow this change.
>>>>
>>>> I uploaded a webrev for this issue. This webrev is generated from 
>>>> consolidated repo (jdk10/master).
>>>> Could you review it?
>>>>
>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8187597/webrev.00/
>>>>
>>>>
>>>> I cannot access JPRT. So I need reviewer.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>
>>>