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

ZGC: Long concurrent select relocation set phase when heap size is large

    XMLWordPrintable

    Details

    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 16
    • Fix Version/s: 16
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
      gc

      Description

      One can use `-Xlog:gc+phases` to report how much time is spent in each phase of GC. While running SPECJBB2015 with ZGC, quite a few GC cycles stand out with long "concurrent select relocation set" phase. That phase alone could take up to 2 seconds while marking/relocation each takes ~500ms.

      Here is rough analysis on what's performed in "concurrent select relocation set" phase, and the number of potential expensive operations (lock/unlock, calling malloc):

      1.a identify all sparse pages for relocation; assuming N sparse pages, then O(logN) number of calls to malloc to hold all live pages. (A growable array is used internally, which doubles its capacity on overflow.)
      1.b identify all empty pages to be placed in page cache; assuming E empty pages, then O(E) number of lock/unlock calls. (Freeing a page requires holding a lock in `ZPageAllocator`.)

      2.a. sort N spare pages to pick the first M elements to be placed in EC (Evacuation Candidates). O(1) number of calls to malloc
      2.b. create a forwarding table for each page. O(M) number of calls to malloc

      3. create an array, holding all pages in EC, O(1) number of calls to malloc

      For some GC cycles, N ~ 80K, E ~ 10K and M ~ 50K.

        Attachments

          Activity

            People

            Assignee:
            ayang Albert Yang
            Reporter:
            ayang Albert Yang
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: