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

Filipp Zhinkin filipp.zhinkin at oracle.com
Tue Nov 25 07:26:42 UTC 2014


Dima,
thank you for review!

Jon,
would you mind sponsoring this change?

Regards,
Filipp.

On 11/24/2014 04:29 PM, Dmitry Fazunenko wrote:
> 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