8191227: issues with unsafe handle resolution

Added ThreadInVMfromNative or ThreadInVMfromUnknown support

Reviewed-by: thartmann, vlivanov
This commit is contained in:
Rahul Raghavan 2017-11-27 03:11:38 -08:00
parent 925a508b2b
commit 250c05ee4c
2 changed files with 21 additions and 4 deletions

View File

@ -398,8 +398,13 @@ void LIR_Assembler::jobject2reg(jobject o, Register reg) {
if (o == NULL) {
__ set(NULL_WORD, reg);
} else {
#ifdef ASSERT
{
ThreadInVMfromNative tiv(JavaThread::current());
assert(Universe::heap()->is_in_reserved(JNIHandles::resolve(o)), "should be real oop");
}
#endif
int oop_index = __ oop_recorder()->find_index(o);
assert(Universe::heap()->is_in_reserved(JNIHandles::resolve(o)), "should be real oop");
RelocationHolder rspec = oop_Relocation::spec(oop_index);
__ set(NULL_WORD, reg, rspec); // Will be set when the nmethod is created
}

View File

@ -28,6 +28,8 @@
#include "code/nmethod.hpp"
#include "oops/oop.inline.hpp"
#include "runtime/handles.inline.hpp"
#include "runtime/interfaceSupport.hpp"
#include "runtime/thread.hpp"
// Constructors
@ -209,14 +211,24 @@ void ConstantDoubleValue::print_on(outputStream* st) const {
// ConstantOopWriteValue
void ConstantOopWriteValue::write_on(DebugInfoWriteStream* stream) {
assert(JNIHandles::resolve(value()) == NULL ||
Universe::heap()->is_in_reserved(JNIHandles::resolve(value())),
"Should be in heap");
#ifdef ASSERT
{
// cannot use ThreadInVMfromNative here since in case of JVMCI compiler,
// thread is already in VM state.
ThreadInVMfromUnknown tiv;
assert(JNIHandles::resolve(value()) == NULL ||
Universe::heap()->is_in_reserved(JNIHandles::resolve(value())),
"Should be in heap");
}
#endif
stream->write_int(CONSTANT_OOP_CODE);
stream->write_handle(value());
}
void ConstantOopWriteValue::print_on(outputStream* st) const {
// using ThreadInVMfromUnknown here since in case of JVMCI compiler,
// thread is already in VM state.
ThreadInVMfromUnknown tiv;
JNIHandles::resolve(value())->print_value_on(st);
}