JDK-8169711 : CDS does not patch entry trampoline if intrinsic method is disabled
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-11-15
  • Updated: 2019-12-22
  • Resolved: 2016-11-21
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 9
9 b150Fixed
Related Reports
Relates :  
JDK-8169867 - Method::restore_unshareable_info() does not invoke Method::link_method()
Relates :  
JDK-8154122 - Intrinsify fused mac operations on x86
Relates :  
JDK-8170767 - Zero fastdebug build triggers assertion
Relates :  
JDK-8145221 - Use trampolines for i2i and i2c entries in Methods that are stored in CDS archive
Description
JDK-8154122 introduce new flag "UseFMA". Running following sequence of commands cause fastdebug Java 9(b140 and later) to crash on my Linux amd64 system:
java -Xshare:dump
java -XX:-UseFMA -XX:+UseSharedSpaces -version
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/method.cpp:982
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/scratch/opt/jprt/T/P1/002850.jianzhou/s/hotspot/src/share/vm/oops/method.cpp:982), pid=16543, tid=16545
#  assert(entry == _i2i_entry && entry == _from_interpreted_entry) failed: should be correctly set during dump time
#
# JRE version:  (9.0) (fastdebug build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-11-15-002850.jianzhou.jdk9, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /home/ddmitriev/work/nightly_bundles/nightly.2016-11.15/bin/core.16543)
#
# An error report file with more information is saved as:
# /home/ddmitriev/work/nightly_bundles/nightly.2016-11.15/bin/hs_err_pid16543.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

hs_err_pid16543.log is attached.
Comments
Location of the patch in the consolidated repo http://hg.openjdk.java.net/jdk/jdk/rev/56304dee97f3
22-12-2019
When dumping metadata with class data sharing (CDS), Method::unlink_method() takes care of removing all entry points of methods that will be shared. The _i2i and _from_interpreted entries are set to the corresponding address in the _cds_entry_table (see AbstractInterpreter::entry_for_cds_method()). This address points to a trampoline in shared space that jumps to the actual (unshared) interpreter method entry at runtime (see AbstractInterpreter::update_cds_entry_table()). Intrinsic methods may have a special interpreter entry (for example, 'Interpreter::java_lang_math_fmaF') and if they are shared, their entry points are set to such a trampoline that is patched at runtime to jump to the interpreter stub containing the intrinsic code. The problem is that if an intrinsic is enabled during dumping but disabled during re-using the shared archive, the trampoline is not patched and therefore still refers to the old stub address that was only valid during dumping. In debug, we hit the "should be correctly set during dump time" assert in Method::link_method() because the method entries are inconsistent. In product, we crash because we jump to an invalid address through the unpatched trampoline. This problem exists with the FMA, CRC32 and CRC32C intrinsics (see attached regression test, the CRC32C problem is only triggered if java/util/zip/CRC32C is added to the classlist).
17-11-2016
While testing, I noticed that the assert in Method::link_method() is not always triggered (sometimes we just crash). This is because 1) the "_from_compiled_entry == NULL" check in Method::restore_unshareable_info() is always false and therefore link_method() is not invoked and 2) in Method::link_method() we only execute the check if the adapter (which is shared) was not yet initialized. I filed JDK-8169867 for this because I'm not too familiar with the CDS internals.
17-11-2016
ILW = assert when linking method, only with CDS and -XX:-UseFMA, no workaround = MMH = P3
15-11-2016