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

Make TestGCLocker more resilient with concurrent GCs

    XMLWordPrintable

Details

    • gc
    • b34
    • generic
    • 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

                rkennke Roman Kennke
                rkennke Roman Kennke
                Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: