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

Shenandoah Generational: Relax enforcement of evacuation budgets



    • Enhancement
    • Resolution: Fixed
    • P4
    • None
    • None
    • hotspot
    • gc
    • generic
    • generic


      To support borrowing from old-gen memory during evacuation and updating of references, and to support more efficient pacing of allocation during GC, we set aside certain memory to hold the results of evacuation (both old-gen and young-gen) at the start of each evacuation pass.
      Because of fragmentation between thread-local buffers, it is possible that evacuation will fail even though the evacuation budget is generally much larger than the amount of memory that needs to be evacuated. This is because the total evacuation budget is divided into plabs, there's some waste at the end of each plab, and sometimes the thread that needs to evacuate an object cannot allocate memory to hold the evacuation even though other threads have "plenty" of memory available in their previously allocated plab or gclab buffers.
      If an evacuation allocation fails, concurrent GC degenerates, resulting in long stop-the-world pauses. We desire to avoid this condition:

      1. If a young-gen evacuation exceeds the young-gen evacuation reserve but there is still plenty of memory available for allocating young objects while concurrent GC continues, allow the evacuation allocation to succeed, but "charge" the allocation to the mutator. With regards to ShenandoahPacing, for example, the mutator's "concurrent allocation budget" is reduced by the amount of evacuation budget overrun.
      2. If an old-gen evacuation exceeds the old-gen evacuation reserve, but there is still plenty of memory available in old-gen, allow the evac allocation to succeed, but make budgeting adjustments if necessary. In particular, if old-gen had already "loaned" the memory required for this old-gen evacuation to young-gen, decrease the amount of loaned memory that can be newly allocated. In other words, account for the allocated promotion memory as if it were newly allocated memory.
      3. If a promotion exceeds the promotion reserve, just reject the promotion and allow the object to be promoted during a subsequent evacuation phase. Failure to promote is relatively harmless.




            wkemper William Kemper
            kdnilsen Kelvin Nilsen
            0 Vote for this issue
            2 Start watching this issue