-
Bug
-
Resolution: Fixed
-
P3
-
8, 9, 10
-
b36
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8240093 | openjdk8u252 | Rahul Raghavan | P3 | Resolved | Fixed | b05 |
There's an assert in ConstantOopWriteValue::write_on() which does JNIHandles::resolve(). The problem is current thread is compiler thread and it isn't in VM (but in native) at that moment. So, it's unsafe to resolve a handle and access the naked oop.
void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) {
assert(JNIHandles::resolve(value()) == NULL ||
Universe::heap()->is_in_reserved(JNIHandles::resolve(value())),
"Should be in heap");
stream->write_int(CONSTANT_OOP_CODE);
stream->write_handle(value());
}
Original report:
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-November/027546.html
void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) {
assert(JNIHandles::resolve(value()) == NULL ||
Universe::heap()->is_in_reserved(JNIHandles::resolve(value())),
"Should be in heap");
stream->write_int(CONSTANT_OOP_CODE);
stream->write_handle(value());
}
Original report:
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-November/027546.html
- backported by
-
JDK-8240093 Unsafe handle resolution in ConstantOopWriteValue::write_on() / print_on() and LIR_Assembler::jobject2reg()
-
- Resolved
-
- blocks
-
JDK-8167372 Add code to check for getting oops while thread is in native
-
- Resolved
-
- relates to
-
JDK-8193699 AArch64: Fails to build after 8167372
-
- Closed
-