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

Make TestGCLocker more resilient with concurrent GCs

    Details

    • Subcomponent:
      gc
    • Resolved In Build:
      b34
    • CPU:
      generic
    • OS:
      generic

      Backports

        Description

        TestGCLocker seems to be made with the assumption that GCs are triggered on allocation failure. It has a somewhat complicated machinery to generate some GC pressure and especially to free up some memory in its artificial MemoryUser. This leads to some weird interactions with Shenandoah control machinery.

        For example, it frees memory when heap usage is >75% AND a certain time has passed since it last freed memory (500ms). In those 500ms, it will keep on allocating chunks of memory, eventually running OOM because it keeps holding on to those chunks, while the GC is running like mad trying to free up memory, but can't because the stupid up doesn't let go. However, it will still keep resetting timeSinceLastGC because of some tiny objects getting freed-up since last time (not enough to prevent OOM though).

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  rkennke Roman Kennke
                  Reporter:
                  rkennke Roman Kennke
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  1 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: