JDK-8162766 : Unsafe_DefineClass0 accesses raw oops while in _thread_in_native
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8u40
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2016-07-29
  • Updated: 2017-11-29
  • Resolved: 2016-10-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7Resolved 8u152 b01Fixed
Related Reports
Relates :  
The problem is that get_class_loader resolves handles while in native. 

If line 989 gets executed while GC is moving cls then we may get an incorrect value or even a crash if we are unlucky.
The same goes for line 992.
At line 993 and 994 we may read a stale value for k->class_loader() and return a JNI handle to an invalid object.

 988 static jobject get_class_loader(JNIEnv* env, jclass cls) {
 989   if (java_lang_Class::is_primitive(JNIHandles::resolve_non_null(cls))) {
 990     return NULL;
 991   }
 992   Klass* k = java_lang_Class::as_Klass(JNIHandles::resolve_non_null(cls));
 993   oop loader = k->class_loader();
 994   return JNIHandles::make_local(env, loader);
 995 }

Suggested fix is to call get_class_loader before transitioning to native in Unsafe_DefineClass0

See email trail at:
I am marking this issue as ���Not Verified���, as there is no test case nor PoC, nor Regression test cases are available. Moreover, this is already marked with labels: noreg-hard

Issue seems introduced in 8u40 (according to Mikael). Not urgent, but should be fixed.