RFR(S): 8132721: Add tests which check that heap counters work as expected during Humongous allocations

Dmitry Fazunenko dmitry.fazunenko at oracle.com
Tue Feb 2 12:25:36 UTC 2016


Hi Kirill,

In general the test looks good.

A few minor comments:

1) copyrights 2015 -> 2016
2) Would you consider to move
gcBeans.stream().mapToLong(GarbageCollectorMXBean::getCollectionCount).sum();
into a separate method. You use this construct twice.

3) You print debug info:

             System.out.println("Counter returned that allocation used " + (usedMemoryAfter - usedMemoryBefore) + "; "
                     + "expected allocation size at least " + expectedAllocationSize * ALLOCATION_SIZE_TOLERANCE_FACTOR);

  for the sake of simplification debug in case of failure, it's better 
to print separately:
- allocationSize, usedMemoryBefore, usedMemoryAfter.

4)

             if (gcCountNow == gcCountBefore) {
                 ...
             } else {
                 System.out.println("GC happened during allocation so the check is skipped");
             }

In case of an unexpected GC happens on iteration #3, all the following 
iterations will be skipped.
But you can skip only iteration #3. For that in the 'else' branch you 
need to add
         gcCountBefore = gcCountNow

Thanks,
Dima



On 01.02.2016 22:04, Kirill Zhaldybin wrote:
> Dear all,
>
> Could you please take a look at this test for JDK-8132721?
>
> The test allocates/deallocates humongous objects and checks that 
> memory counters (from Runtime and MemoryMXBean classes) work right.
>
> For example it's expected that after allocating HO of size
> (G1Region/2 + 1) bytes free memory should decrease on full G1Region
> size.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8132721
>
> WebRev:
> http://cr.openjdk.java.net/~kzhaldyb/webrevs/JDK-8132721/webrev.04/
>
>
> Thank you.
> Regards, Kirill
>



More information about the hotspot-gc-dev mailing list