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

[Filipp Zhinkin]

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?
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?

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.