IV20330: ASSERTION FAILURE IN CACHEMAP.CPP

Subscribe

You can track all active APARs for this component.

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 number

    IV20330

  • Reported component name

    J9 COMMON CODE

  • Reported component ID

    620700127

  • Reported release

    260

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-04-27

  • Closed date

    2012-04-27

  • Last modified date

    2012-04-27

  • 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



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Runtimes for Java Technology
Virtual Machine

Software version:

260

Reference #:

IV20330

Modified date:

2012-04-27

Translate my page

Machine Translation

Content navigation