Hi, I missed that there was another commit to revert.
(obviously if we have jlong here and it is long you will get that exception
but there might be an old bug regrading long 32/64, e.g. CInt)
Your fix looks correct, thanks for fixing!
/Robbin
[rehn@rehn-ws hotspot]$ hg log -r13303 -p
changeset: 13303:777b211c54ba
parent: 13301:681389dce7a6
user: rkennke
date: Mon Jul 24 17:14:32 2017 +0200
summary: 8185102: TestSAServer.java fails due to
"sun.jvm.hotspot.types.WrongTypeException: field "_stack_traversal_mark"
diff -r 681389dce7a6 -r 777b211c54ba
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java
--- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java
Mon Jul 24 09:32:35 2017 -0400
+++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/code/NMethod.java
Mon Jul 24 17:14:32 2017 +0200
@@ -71,7 +71,7 @@
stack. An not_entrant method can be removed when there is no
more activations, i.e., when the _stack_traversal_mark is less than
current sweep traversal index. */
- private static CIntegerField stackTraversalMarkField;
+ private static JLongField stackTraversalMarkField;
private static CIntegerField compLevelField;
@@ -105,7 +105,7 @@
verifiedEntryPointField =
type.getAddressField("_verified_entry_point");
osrEntryPointField = type.getAddressField("_osr_entry_point");
lockCountField = type.getJIntField("_lock_count");
- stackTraversalMarkField =
type.getCIntegerField("_stack_traversal_mark");
+ stackTraversalMarkField = type.getJLongField("_stack_traversal_mark");
compLevelField = type.getCIntegerField("_comp_level");
pcDescSize = db.lookupType("PcDesc").getSize();
}
On 09/18/2017 03:54 PM, Yasumasa Suenaga wrote:
So it looks like you are running tools from an older build with a newer vm or
something like that ?
No. I've applied this change to changeset 47219.
----------------
changeset: 47219:fd36993f7bf5
tag: tip
user: ihse
date: Fri Sep 15 09:18:00 2017 -0700
summary: 8187542: Remove superfluous *_TOPDIR variables
----------------
I've tested jshell and HSDB from this source.
Yasumasa
On 2017/09/18 22:14, 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.
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
