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

Dmitry Fazunenko dmitry.fazunenko at oracle.com
Mon Nov 24 12:29:31 UTC 2014


Hi Filipp,

The new version looks good to me.

Thanks
Dima

On 24.11.2014 14:22, Filipp Zhinkin wrote:
> Hi all,
>
> I'm still looking for a second review.
> Everyone is welcome. ;)
>
> Regards,
> Filipp.
>
> On 10/29/2014 08:02 PM, Filipp Zhinkin wrote:
>> Hi Jon,
>>
>> thank you for looking at it!
>>
>> On 10/29/2014 08:07 PM, Jon Masamitsu wrote:
>>> 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.
>> Sure:
>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/f7cb546710c8/test/testlibrary/com/oracle/java/testlibrary/cli/CommandLineOptionTest.java#l71 
>>
>>
>> Thanks,
>> Filipp.
>>>
>>> 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 
>>>>>
>>>>
>>>
>>
>



More information about the hotspot-gc-dev mailing list