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

Filipp Zhinkin filipp.zhinkin at oracle.com
Mon Oct 27 13:58:16 UTC 2014


friendly reminder

On 10/07/2014 01:33 PM, Filipp Zhinkin wrote:
> 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