IV20330: ASSERTION FAILURE IN CACHEMAP.CPP

APAR status

• Closed as program error.

Error description

• Error Message: j9shr.1015   *   ** ASSERTION FAILED ** at
  CacheMap.cpp:1476: ((_ccHead->getReaderCount(currentThread) !=
  0))
  .
  Stack Trace: SH_CacheMap::runEntryPointChecks () from
  jre/lib/ppc/default/libj9shr26.so
  SH_CacheMap::findROMClassResource () from
  jre/lib/ppc/default/libj9shr26.so
  SH_CacheMap::findAttachedData () from
  jre/lib/ppc/default/libj9shr26.so
  SH_CacheMap::findAttachedDataAPI () from
  jre/lib/ppc/default/libj9shr26.so
  j9shr_findAttachedData () from jre/lib/ppc/default/libj9shr26.so
  TR_J9VMBase::getSharedCacheHint () from
  jre/lib/ppc/default/libj9jit26.so
  TR_J9VMBase::isSharedCacheHint () from
  jre/lib/ppc/default/libj9jit26.so
  jitHookInitializeSendTarget () from
  jre/lib/ppc/default/libj9jit26.so
  J9HookDispatch () from jre/lib/ppc/default/libj9hookable26.so
  initializeMethodRunAddress () from
  jre/lib/ppc/default/libj9vm26.so
  internalCreateRAMClassFromROMClassImpl () from
  jre/lib/ppc/default/libj9vm26.so
  internalCreateRAMClassFromROMClass () from
  jre/lib/ppc/default/libj9vm26.so
  foundROMClass () from jre/lib/ppc/default/libj9vm26.so
  attemptDynamicClassLoad () from jre/lib/ppc/default/libj9vm26.so
  internalFindClassUTF8 () from jre/lib/ppc/default/libj9vm26.so
  internalFindClassString () from jre/lib/ppc/default/libj9vm26.so
  L14 () from jre/lib/ppc/default/libjclscar_26.so
  internalFindClassUTF8 () from jre/lib/ppc/default/libj9vm26.so
  resolveClassRef () from jre/lib/ppc/default/libj9vm26.so
  L109 () from jre/lib/ppc/default/libj9vm26.so
  .
  

Local fix

• This problem can be prevented by disabling the shared class
  cache using -Xshareclasses:none.
  

Problem summary

• When a JVM wants to lock the shared class cache for updating the
  cache, it must wait for other JVMs to release read-locks on the
  cache. There is a timeout for waiting, since a crashed or hung
  JVM may leave a read-lock on the cache. After the timeout, the
  JVM could assert under certain conditions if the read-locks are
  not all cleared.
  In a heavily loaded environment, it can happen there are enough
  readers attached to the shared cache to exhaust the JVM's
  timeout period.
  

Problem conclusion

• This defect will be fixed in:
  6.0.1 SR2
  7.0.0 SR1
  .
  The timeout for locking the cache has been increased
  sufficiently to allow existing readers to complete their work.
  Also this particular assertion has been removed as this
  condition is not fatal.
  

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

  J9 COMMON CODE

• Fixed component ID

  620700127

Applicable component levels

• R260 PSY

     UP