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

[Jon Masamitsu]

Filipp,

Sorry for the delay.  These tests look good.

Can you point me at the source for

   59         CommandLineOptionTest.verifyJVMStartup(


I just want to see what the messages are where there is
a failure.

Thanks.

Jon

On 10/27/2014 6:58 AM, Filipp Zhinkin wrote:
> 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 
>>
>