[9] RFR (L): 8037968: Add tests on alignment of objects copied to survivor space

Filipp Zhinkin filipp.zhinkin at oracle.com
Tue Oct 7 09:33:22 UTC 2014


Hi all,

please review tests on survivor alignment feature (JDK-8031323 [1]).

Webrev: http://cr.openjdk.java.net/~fzhinkin/8037968/webrev.00/
Bug id: https://bugs.openjdk.java.net/browse/JDK-8037968
Testing: manual, automated
Description:

There are 6 new tests:
one verifies SurvivorAlignmentInBytes option processing
and other 5 tests verify that that option only affect alignment
of objects copied to survivor space and that their alignment is
equal to SurvivorAlignmentInBytes value.

Since there are no guarantee that _all_ objects copied to
survivor space will be alignedthese tests are verifying that
objects occupy some expected amount of memory depending on alignment.

All tests use following algorithm:
- decide how many objects should be allocated
- allocate objects
- force minor or full GCs if needed
- verify usage of particular heap space (eden, survivor or tenured).

There are several differences between Hotspot garbage collectors that affect
memory usage measurements:
1) precision of such measurements;
2) min amount of heap space that will be occupied by a single object.

The first one is about the G1 GC, where usage of eden and survivor regions
is reported as (number_of_used_regions * G1HeapRegionSize) [2].

Tests verify that actual memory usage is close to expected usage,
i.e. difference between actual and expected usage hasto be lower
or equal to 5% of expected usage.
However, for G1 GC max allowed difference has to be aligned up to G1HeapRegionSize.

The second one is about the CMS GC, where an objecthas to occupy at least
MinChunkSize bytes [3][4].

And, of course, amount of memory occupied by an object depends on the alignment
used in particular heap space: SurvivorAlignmentInBytes for survivor space and
ObjectsAlignmentInBytes for other spaces.

To take all such aspects into account tests use AlignmentHelper class,
whose instances are created for each heap space.

That class is aimed to answer following questions:
- how much space will be occupied by an object whose size is M;
- how many objects of size M should be allocated to occupy N bytes
of memory in particular heap space;
- how much space will be occupied by K objects whose size is M;
- how close the actual memory usage has to be to the expected memory usage
given the precision with which we can measure the memory usage.

In order to avoid false failures caused by memory allocated by different threads
(for example, some agent was attached to tested JVM and allocated objects during
the test run) tests check that only the main test thread was allocating objects.

Thanks,
Filipp.

[1] https://bugs.openjdk.java.net/browse/JDK-8031323
[2] 
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/5c722dffbc0f/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp#l124
[3] 
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/5c722dffbc0f/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp#l1427
[4] 
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/5c722dffbc0f/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp#l477 



More information about the hotspot-gc-dev mailing list