IBM Support

IJ32248: OBJECT GARBAGE COLLECTED WHEN LIVE REFERENCES STILL EXISTS

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • Closed as program error.

Error description

  • Error Message: A SIGSEGV when running JIT compiled code. It's
    also possible that the JIT would fail to throw an
    ArrayStoreException, but that problem has never been reported.
    Other symptoms are possible like a GC assert/crash or incorrect
    java program behaviour.
    .
    Stack Trace: N/A
    .
    The problem can only happen when running on zOS or zLinux using
    a 64bit JVM with compressed references. When running without
    compressed references or when the entire heap is located below
    the 4GB barrier this problem is not possible.
    The issue is limited to objects that are located at memory
    addresses that end with 32bits of zeros like 0x100000000. This
    means there are a very small set of addresses that can trigger
    this issue (a maximum of 8 possible addresses when using a 32GB
    heap)
    

Local fix

  • You can use any one of the following to avoid the issue:
    A) Disable compressed references (-Xnocompressedrefs)
    B) Use a heap size of 2GB or less so the heap can fit below the
    4GB boundary (-Xmx2g)
    C) Use the optthruput GC policy, but this will still be
    vulnerable to the missing ArrayStoreException problem.
    (-Xgcpolicy:optthruput)
    

Problem summary

  • The JIT was using a 32bit compare instruction when performing  a
    NULL test to check if we could skip array store checking logic.
    This would allow the NULL test to pass, resulting in a branch
    around the array store checking code when the address of the
    object being stored into the array has all 0 bits in the lower
    32bits of the 64bit address. By skipping the full array store
    check logic, it becomes possible for the GC to free an object
    early or to allow storing an object reference of an illegal type
    to an object array.
    

Problem conclusion

  • The JIT was modified so that the array store check NULL test
    compare uses a 64bit compare instruction.
    .
    This APAR will be fixed in the following Java Releases:
       8    SR6 FP31  (8.0.6.31)
    .
    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 number

    IJ32248

  • Reported component name

    JIT

  • Reported component ID

    620700124

  • Reported release

    130

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2021-04-21

  • Closed date

    2021-04-22

  • Last modified date

    2021-04-22

  • 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

[{"Line of Business":{"code":"LOB36","label":"IBM Automation"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSNVBF","label":"Runtimes for Java Technology"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"130"}]

Document Information

Modified date:
23 April 2021