IJ36090: JAVA JIT CRASH DURING COMPILATION IN GETORIGINALROMMETHOD()

APAR status

• Closed as program error.

Error description

• Error Message: SIGSEGV during JIT compilation
  .
  Stack Trace: {libj9jit29.so}{getOriginalROMMethod}
  {libj9jit29.so}{TR_J9Method::TR_J9Method(TR_FrontEnd*,TR_Memory*
  ,TR_OpaqueMethodBlock*)}
  {libj9jit29.so}{TR_ResolvedJ9Method::TR_ResolvedJ9Method(TR_Opaq
  ueMethodBlock*,TR_FrontEnd*,TR_Memory*,...}
  {libj9jit29.so}{TR_ResolvedJ9Method::getResolvedVirtualMethod(TR
  ::Compilation*,TR_OpaqueClassBlock*,int,bool)}
  {libj9jit29.so}{TR_IndirectCallSite::getResolvedMethod(TR_Opaque
  ClassBlock*)}
  {libj9jit29.so}{TR_ProfileableCallSite::findSingleProfiledReceiv
  er(ListIterator<TR_ProfiledValue<unsign...}
  {libj9jit29.so}{TR_ProfileableCallSite::findProfiledCallTargets(
  TR_CallStack*,TR_InlinerBase*)}
  {libj9jit29.so}{TR_J9VirtualCallSite::findCallSiteTarget(TR_Call
  Stack*,TR_InlinerBase*)}
  {libj9jit29.so}{TR_EstimateCodeSize::isInlineable(TR_CallStack*,
  TR_CallSite*)}
  {libj9jit29.so}{InterpreterEmulator::findTargetAndUpdateInfoForC
  allsite(TR_CallSite*)}
  {libj9jit29.so}{InterpreterEmulator::visitInvokevirtual()}
  {libj9jit29.so}{InterpreterEmulator::findAndCreateCallsitesFromB
  ytecodes(bool,bool)}
  This is an example of the stacktrace seen by one customer. The
  fix addresses three different issues that stem from the same
  scenario.
  .
  The issue can occur on all platforms running the IBM/OpenJ9 JVM,
  but can only occur when shared classes and AOT is enabled.
  

Local fix

• You can avoid the problem by disabling Interpreter Profiling,
  but doing so will have a substantial impact on the quality of
  code that is generated by the JIT compiler because it will lack
  profiling data that the JIT uses to make important compile time
  decisions. Typically performance will degrade by about 5-10%
  using this option.
  -Xjit:disableInterpreterProfiling
  

Problem summary

• The problem can occur when the following conditions are met:
  1. Two identical classes in different class loaders contain a
  method with a virtual call,
  2. The two class loaders have distinct versions of the class
  named at the call site, and
  3. In at least one class loader, the class named at the call
  site does not have its own implementation of the method named at
  the call site, but rather inherits the method from an interface.
  Under such a scenario it's possible for the JIT to attempt a
  virtual function lookup using a virtual function table index
  outside the bounds of the class's function table.
  

Problem conclusion

• The JIT was modified such that profiled class data is properly
  verified to be compatible before the profiled class is allowed
  to be used for inlining of guarded devirtualization purposes.
  https://github.com/eclipse-openj9/openj9/pull/13668
  .
  This APAR will be fixed in the following Java Releases:
     8    SR7 FP5   (8.0.7.5)
  .
  Contact your IBM Product's Service Team for these Service
  Refreshes and Fix Packs.
  For those running stand-alone, information about the available
  Service Refreshes and Fix Packs can be found at:
             https://www.ibm.com/developerworks/java/jdk/
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

• Fixed component name

  JIT

• Fixed component ID

  620700124

Applicable component levels