JDK-8227260 : JNI upcalls should bypass class initialization barrier in c2i adapter
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-07-04
  • Updated: 2021-12-08
  • Resolved: 2019-07-24
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.
JDK 13 JDK 14
13 b31Fixed 14Fixed
Related Reports
Relates :  
JDK-8278416 - Crash during execution of ClassInitBarrier test
Description
The i2c adapter sets a thread-local "callee_target" Method*, which is caught (and cleared) by SharedRuntime::handle_wrong_method if the i2c call is "bad" (e.g. not_entrant). This error handler forwards execution to the callee c2i entry. If the SharedRuntime::handle_wrong_method method is called again due to the i2c2i call being still bad, then we will crash the VM in the following guarantee in SharedRuntime::handle_wrong_method:

Method* callee = thread->callee_target();
guarantee(callee != NULL && callee->is_method(), "bad handshake");

Unfortunately, the c2i entry can indeed fail again if it, e.g., hits the new class initialization entry barrier.

I think a solution to this problem should stop making assumptions about how many things can go wrong when calling a method from the interpreter.

I caught this in ZGC where the timing window for hitting this issue seems to be wider due to concurrent code cache unloading. But it is equally problematic for all GCs.
Comments
URL: https://hg.openjdk.java.net/jdk/jdk13/rev/6a159c6c23cc User: vlivanov Date: 2019-07-24 07:51:41 +0000
24-07-2019
Fix request approved.
23-07-2019
jdk13-fix-request: Fast class initialization barriers (newly introduced in 13 on x86_64, ppc, and s390 platforms) have a problem with JNI upcalls which don't have class initialization barrier. If JNI upcall happens on a not-yet-initialized class (or a class in error state) and the barrier is hit on nmethod entry or in c2i adapter, it crashes the JVM. The bug may manifest itself intermittently and it's hard to work around it in production. So it's desirable to have the fix in 13. The fix passed tier1-6 testing and is part of jdk/jdk: https://hg.openjdk.java.net/jdk/jdk/rev/cff8aad2593f
23-07-2019
Raising priority since it affects JNI upcalls.
17-07-2019