Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8313572

GenShen: Remembered Set verification error in dacapo lusearch

XMLWordPrintable

    • gc
    • generic
    • generic

      Attaching hs_err file and GC log.

      There is an rr recording of this problem available here:
      https://pernos.co/debug/pDWvvnLUgG4FLTBiS7xt9g/index.html

      1. GC(522): we properly copy write table to read table, and clean the write table. Then, when we scan the remembered set, we discover that the pointer is still interesting, and we DIRTY the write table. All good.

      2. GC(523) is a GLOBAL cycle: We cancel an ongoing OLD GC cycle because we're doing GLOBAL. We copy write table to read table and clean the write table. Verify after MARK is happy! But ... we never DIRTIED the write table. Looks like GLOBAL GC marking is failing to update card table AND is failing to verify remembered set after MARK. (it may be that we are trying to verify remembered set, but we do not recognize the problem because we discarded the OLD marking context -- but we should have reconstructed this marking context when we did GLOBAL marking. Note that "normally", we redirty the card table when we scan the remembered set. But for a GLOBAL GC, we need to DIRTY the card table when we mark-through-ref of an OLD object. This is probably where we are missing some code.)

      3. Right after GC(523) ShenandoahFinalMarkStartEvac, we experience a TLAB allocation failure and cancel the GC.

      4. GC(524) announces itself as Degenerated GC (YOUNG) (Outside of Cycle). Methinks this is wrong. It should be Degenerated GC(GLOBAL) (evac). GC(524) copies the write table to read table and cleans the write table. But ... both tables are CLEAN because we had failed to DIRTY the write table when we scanned previous remembered set.

      5. YOUNG GC(525) copies the write table to read table and cleans the write table. Once again, both tables are CLEAN because we failed to DIRTY the write table when we scanned previous remembered set.

      6. OLD GC(526) does coalesce-and-fill old. Then it copies write table to read table and cleans the write table. Once again, both tables are CLEAN because we failed to DIRTY the write table when we scanned previous remembered set. This time, verification of remembered set follows a different path, because we now have an OLD marking context. (Should we not have preserved the OLD marking context that we created during GLOBAL GC(523)?). This time, verify remembered set finds a live old object with an interesting pointer to YOUNG on a CLEAN card.

      Further observations:GC(523) is an abbreviated cycle. Though it appears we aborted before completion, maybe it is ok that we treat the TLAB alloc failure as out of cycle.

            kdnilsen Kelvin Nilsen
            kdnilsen Kelvin Nilsen
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: