IJ44107: JIT PUBLISHES NEW OBJECT REFERENCE TO OTHER THREADS WITHOUT EXECUTING A MEMORY FLUSH

APAR status

• Closed as program error.

Error description

• Error Message: A SIGSEGV is received when executing JIT compiled
  code or in JIT runtime routines.
  .
  Stack Trace: libj9jit29.so fast_jitCheckCast()
  libj9jit29.so jitCheckCast()
  This is an example form a specific instance of the problem,
  other instances will likely show different stack traces.
  .
  The issue allows for a thread to use cached memory that does not
  reflect the current memory state. This means it's possible for
  the JVM to see random memory contents which could result in
  several different failure signatures including but not limited
  to crashes in JIT, JIT compiled code, GC or the VM, as well as
  unexpected exceptions and incorrect behaviour. In practice the
  incorrect cached memory is likely to appear to be filled with 0,
  resulting in crashes due to null pointer dereferences or
  NullPointerExceptions.
  The issue can ONLY appear on POWER hardware (AIX and Linux PPC)
  because of its weak memory coherency architecture requiring
  instructions to ensure memory visibility. This issue is the
  result of a bug in a JIT optimization attempting to remove
  redundant memory flush instructions.
  

Local fix

• The problem can be avoided by disabling the faulty JIT
  optimization by using the following java command line option:
  -Xjit:disableEscapeAnalysis
  Using this option will have some negative effect on throughput
  performance. Typically we would expect a 1-10% performance cost
  when using this option. In some extreme cases the cost could be
  outside this range.
  

Problem summary

• The JIT attempts to remove memory flush instructions for newly
  allocated objects. It does this by looking for other code
  sequences that will require a memory flush instruction, such as
  the exit of a synchronized block. It then removes the allocation
  flush when a suitable sequence is found. But in some cases it's
  possible to exit a synchronized block without executing a memory
  flush, which may allow a reference to a new object to be written
  to the heap before the object's memory has been flushed. This
  allows other threads to access the new object before a memory
  flush is executed, and any thread that does so might see a stale
  copy of the object's memory.
  

Problem conclusion

• The JIT was updated so that a synchronized block will
  unconditionally execute a memory flush instruction when an
  allocation flush was removed based on the existence of the
  synchronized block.
  .
  This APAR will be fixed in the following Releases:
  .
  IBM SDK, Java Technology Edition
   8 SR8 (8.0.8.0)
  .
  Contact your IBM Product's Service Team for these Service
  Refreshes and Fix Packs.
  For those running stand-alone, information about the available
  maintenance can be found at:
   https://www.ibm.com/support/pages/java-sdk
  

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