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

TestHeapCounters.java intermittent failure

    Details

    • Subcomponent:
      gc
    • OS:
      windows

      Description

      gc/g1/humongousObjects/TestHeapCounters.java on test jdk C:\jprt\T\P1\172837.rprotaci\testproduct\windows_x64_6.3-fastdebug failed once on a JPRT run with the following message, passed with no issues upon rerun.

      STDERR:
      java.lang.RuntimeException: Counter of type returned wrong allocation size: expected 1048576 >= 1782579
      at jdk.test.lib.Asserts.fail(Asserts.java:594)
      at jdk.test.lib.Asserts.assertGreaterThanOrEqual(Asserts.java:288)
      at gc.g1.humongousObjects.TestHeapCounters.lambda$main$0(TestHeapCounters.java:186)
      at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1492)
      at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:591)
      at gc.g1.humongousObjects.TestHeapCounters.main(TestHeapCounters.java:177)
      at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
      at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.base/java.lang.reflect.Method.invoke(Method.java:563)
      at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110)
      at java.base/java.lang.Thread.run(Thread.java:844)

      JavaTest Message: Test threw exception: java.lang.RuntimeException: Counter of type returned wrong allocation size: expected 1048576 >= 1782579

        Issue Links

          Activity

          Hide
          ehelin Erik Helin added a comment -
          I marked the bug as a testbug. The problem is that the test tries to verify that a humongous object has been freed by checking the total heap usage before and after a full GC. The issue with that approach is full GC might collect more objects than expected (as can be seen in the first full GC) or it can collect some objects while also promoting other objects. The most likely scenario is that the full GC didn't collect enough memory actually did collect enough memory, but it also promoted some objects that the test (or test harness) had allocated and kept alive. The net difference would be 1 MB, since it would have collected 2MB and used 1MB for the additional region old region used.

          The test should be updated to use e.g. a WhiteBox method or parse the GC logs to ensure that the humongous object was freed, it should not compare the memory usage before and after freeing the humongous object.
          Show
          ehelin Erik Helin added a comment - I marked the bug as a testbug. The problem is that the test tries to verify that a humongous object has been freed by checking the total heap usage before and after a full GC. The issue with that approach is full GC might collect more objects than expected (as can be seen in the first full GC) or it can collect some objects while also promoting other objects. The most likely scenario is that the full GC didn't collect enough memory actually did collect enough memory, but it also promoted some objects that the test (or test harness) had allocated and kept alive. The net difference would be 1 MB, since it would have collected 2MB and used 1MB for the additional region old region used. The test should be updated to use e.g. a WhiteBox method or parse the GC logs to ensure that the humongous object was freed, it should not compare the memory usage before and after freeing the humongous object.

            People

            • Assignee:
              Unassigned
              Reporter:
              rprotacio Rachel Protacio (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: