[9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests

Filipp Zhinkin filipp.zhinkin at oracle.com
Thu Dec 25 09:37:55 UTC 2014


Thank you, Igor!

Regards,
Filipp.

On 12/25/2014 01:42 PM, Igor Ignatyev wrote:
> Filipp,
>
> looks good to me.
>
> Thanks,
> Igor
>
> On 12/24/2014 07:33 PM, Filipp Zhinkin wrote:
>> Hi all,
>>
>> please take a look at updated tests.
>> This time an issue with server JVMs that don't support tiered
>> compilation was resolved.
>>
>> incremental diff:
>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.02.inc/
>> new webrev: http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.02/
>> testing: JPRT & local (using server embedded JVM which does not support
>> tiered comp).
>>
>> This change is also depends on
>> https://bugs.openjdk.java.net/browse/JDK-8068183.
>>
>> Thanks,
>> Filipp.
>>
>> On 12/23/2014 11:37 AM, Filipp Zhinkin wrote:
>>> Thank you, Christian!
>>>
>>> Regards,
>>> Filipp.
>>>
>>> On 12/22/2014 09:01 PM, Christian Thalinger wrote:
>>>> Yes, looks good.
>>>>
>>>>> On Dec 22, 2014, at 7:06 AM, Filipp Zhinkin
>>>>> <filipp.zhinkin at oracle.com> wrote:
>>>>>
>>>>> Christian, are you ok with the latest fix version?
>>>>>
>>>>> Thanks,
>>>>> Filipp.
>>>>>
>>>>> On 12/19/2014 02:33 PM, Filipp Zhinkin wrote:
>>>>>> Christian, thank you for review!
>>>>>>
>>>>>> I've updated tests to reflect WhiteBox movement to top-level repo,
>>>>>> added previously missed @bug tag and fixed few small issues:
>>>>>>
>>>>>> incremental diff:
>>>>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01.inc/
>>>>>>
>>>>>> updated webrev:
>>>>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.01/
>>>>>>
>>>>>> Thanks,
>>>>>> Filipp.
>>>>>>
>>>>>> On 12/19/2014 02:19 AM, Christian Thalinger wrote:
>>>>>>> Looks good.
>>>>>>>
>>>>>>>> On Dec 10, 2014, at 4:39 AM, Tobias Hartmann
>>>>>>>> <tobias.hartmann at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi Filipp,
>>>>>>>>
>>>>>>>> On 10.12.2014 13:21, Filipp Zhinkin wrote:
>>>>>>>>> Tobias,
>>>>>>>>>
>>>>>>>>> as I wrote you in a private message, until a fix for 8064940
>>>>>>>>> doesn't affect
>>>>>>>>> the way options are processed there is no need to update
>>>>>>>>> proposed tests.
>>>>>>>>>
>>>>>>>>> I've filed 8067135 for new tests that will verify actual
>>>>>>>>> alignment of code heaps.
>>>>>>>> Okay, sounds good.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tobias
>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Filipp.
>>>>>>>>>
>>>>>>>>> On 12/08/2014 06:18 PM, Filipp Zhinkin wrote:
>>>>>>>>>> On 12/08/2014 06:12 PM, Tobias Hartmann wrote:
>>>>>>>>>>> On 08.12.2014 13:25, Filipp Zhinkin wrote:
>>>>>>>>>>>> Hi Tobias,
>>>>>>>>>>>>
>>>>>>>>>>>> thank you for suggestion.
>>>>>>>>>>>>
>>>>>>>>>>>> Yes, I think we should take code heap size alignment into
>>>>>>>>>>>> account.
>>>>>>>>>>>>
>>>>>>>>>>>> What alignment policy you're going to implement for 8064940?
>>>>>>>>>>> My current fix just large-page-aligns the code heap sizes.
>>>>>>>>>>>
>>>>>>>>>>>> Maybe instead of checking that values are in
>>>>>>>>>>>> (value - page_size, value + page_size) interval we should
>>>>>>>>>>>> just check
>>>>>>>>>>>> that all values were aligned up to page_size?
>>>>>>>>>>> Yes, that's a better solution. However, I don't know how to
>>>>>>>>>>> figure out the
>>>>>>>>>>> available page sizes from Java code.
>>>>>>>>>> There's Unsafe::pageSize() method. Also, I saw a RFR on hs-rt list
>>>>>>>>>> about to add such method to WB API, but it need to check how well
>>>>>>>>>> it is going to work with large pages.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Filipp.
>>>>>>>>>>> Best,
>>>>>>>>>>> Tobias
>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Filipp.
>>>>>>>>>>>>
>>>>>>>>>>>> On 12/08/2014 12:37 PM, Tobias Hartmann wrote:
>>>>>>>>>>>>> Hi Filipp,
>>>>>>>>>>>>>
>>>>>>>>>>>>> the actual size of a code heap is affected by alignment and
>>>>>>>>>>>>> therefore may be
>>>>>>>>>>>>> different to the size set via the command line. For example,
>>>>>>>>>>>>> on Sparc we
>>>>>>>>>>>>> have to
>>>>>>>>>>>>> make sure that the code heaps are large page (4MB) aligned
>>>>>>>>>>>>> to reduce the
>>>>>>>>>>>>> number
>>>>>>>>>>>>> of ITLB misses (will be introduced with [1]).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe we should check if the actual size of the code heap is
>>>>>>>>>>>>> within
>>>>>>>>>>>>> boundaries,
>>>>>>>>>>>>> i.e., within the specified size +- (large) page size.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Tobias
>>>>>>>>>>>>>
>>>>>>>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8064940
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 05.12.2014 18:06, Filipp Zhinkin wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> please take a look at CLI tests for segmented code cache
>>>>>>>>>>>>>> (JDK-8059623).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> There are three new tests:
>>>>>>>>>>>>>> compiler/codecache/cli/
>>>>>>>>>>>>>>     codeheapsize/TestCodeHeapSizeOptions
>>>>>>>>>>>>>> printcodecache/TestPrintCodeCacheOption
>>>>>>>>>>>>>>     TestSegmentedCodeCacheOption
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All tests consist of several test cases aimed to verify
>>>>>>>>>>>>>> different aspects
>>>>>>>>>>>>>> of options' processing.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> These tests partially overlapped with
>>>>>>>>>>>>>> c/c/CheckSegmentedCodeCache test,
>>>>>>>>>>>>>> but add additional value - these tests actually check final
>>>>>>>>>>>>>> values
>>>>>>>>>>>>>> of tested options and verifies PrintCodeCache output.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8059623
>>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~fzhinkin/8059623/webrev.00/
>>>>>>>>>>>>>> Testing: manual & automated
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This change depends on:
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8054892: Improve
>>>>>>>>>>>>>> compiler's CLI
>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>> error reporting
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440: Various
>>>>>>>>>>>>>> changes in
>>>>>>>>>>>>>> testlibrary
>>>>>>>>>>>>>> for JDK-8059613
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Filipp.
>>>
>>



More information about the hotspot-compiler-dev mailing list