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

Filipp Zhinkin filipp.zhinkin at oracle.com
Mon Dec 29 09:54:04 UTC 2014


Thank you, Goetz!

Regards,
Filipp.

On 12/29/2014 12:58 PM, Lindenmaier, Goetz wrote:
> Looks good and works fine on ppc,
>
> Thanks a lot!
>    Goetz.
>
> -----Original Message-----
> From: Filipp Zhinkin [mailto:filipp.zhinkin at oracle.com]
> Sent: Wednesday, December 24, 2014 5:34 PM
> To: hotspot-compiler-dev at openjdk.java.net
> Cc: Christian Thalinger; Lindenmaier, Goetz
> Subject: Re: [9] RFR (L): 8059623: JEP-JDK-8043304: Test task: command line options tests
>
> 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