RFR: 8059613 -JEP-JDK-8043304: Test task: JMX- tests and JDK-8066440 - Various changes in testlibrary for JDK-8059613

[Staffan Larsen]

I would favor a solution where the iteration count is an argument to the test instead of being a global variable.

/Staffan

> On 9 dec 2014, at 11:36, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
> 
> On 12/09/2014 01:20 PM, Staffan Larsen wrote:
>> 
>>> On 9 dec 2014, at 11:11, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>> 
>>> I treat 'iteration count' as 'the number of times the test should be run', where by the test implies the main loop of the test. I don't insist that it has to be called 'ITERATION_COUNT'. if you have better name for this, let's use it.
>>> 
>>> another application of such a parameter is limitation of test cases count in the tests which iterate over set of generated test cases.
>>> 
>>> also we have tests which run several times to get an averaged value for some indicator (elapsed time. used memory, etc)
>>> 
>>> for all of these cases, I'd like to use one variable.
>> 
>> But these look like three different counters to me? And for some tests all three counter could possibly be needed.
>> 
>> I note that there are has been related discussions on the jdk side about needing some way to turn a dial from “quick but less coverage” to “slow but with more coverage” for some types of tests.
> well, what about renaming ITERATION_COUNT to TEST_RUN_COUNT and having it in common lib?
> 
> // on jdk-side in j.l.invoke tests, we do have IS_THOROUGH switch, which turns the tests from 'limited time' mode to 'cover all combinations' one.
> 
> -- Igor
>> 
>> /Staffan
>> 
>>> 
>>> Thanks,
>>> Igor
>>> 
>>> On 12/09/2014 12:59 PM, Staffan Larsen wrote:
>>>> But what is an “iteration count”? It does not seem to be “the number of times the test should be run”, but more “how many times an arbitrary loop should be run”. And it is the “arbitrary” that I have a problem with. Iteration of what? When/if we port these old tests, should we not try to clean this up and make it less arbitrary? Or is there some design choice in the tests that I am missing?
>>>> 
>>>> /Staffan
>>>> 
>>>> 
>>>>> On 9 dec 2014, at 10:34, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>> 
>>>>> Staffan, by 'porting our existing tests' I didn't mean porting existing tests for codecache. I meant all other tests, including svc, gc, rt tests. many of them have iteration count as a parameter, so having a common way to set/get it looks needful from my point of view.
>>>>> 
>>>>> On 12/08/2014 09:59 AM, Staffan Larsen wrote:
>>>>>> I still don’t think this looks general-purpose enough to have it included in the general test library. If you need a parameter for your tests, then I would suggest adding it to some class under test/compiler/codecache.
>>>>>> 
>>>>>> /Staffan
>>>>>> 
>>>>>>> On 5 dec 2014, at 22:28, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hi Staffan,
>>>>>>> 
>>>>>>> Utils.ITERATION_COUNT will be extremely useful during porting our existing tests. so I'd like to have it in common testlibrary.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Igor
>>>>>>> 
>>>>>>> On 12/05/2014 11:13 PM, Dmitrij Pochepko wrote:
>>>>>>>> During internal team review, Igor.Igntatyev asked to move it to Utils,
>>>>>>>> perhaps he has future plans for this.
>>>>>>>> Igor?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Dmitrij
>>>>>>>>> Utils.ITERATION_COUNT does not look like something that is usable
>>>>>>>>> outside these specific tests? Should it really be part of the test
>>>>>>>>> library?
>>>>>>>>> 
>>>>>>>>>> On 5 dec 2014, at 18:18, Dmitrij
>>>>>>>>>> Pochepko<Dmitrij.Pochepko at oracle.COM>  wrote:
>>>>>>>>>> 
>>>>>>>>>> Adding hotspot-dev for wider audience.
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> Please review changes for
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8059613 - JEP-JDK-8043304:
>>>>>>>>>>> Test task: JMX- tests
>>>>>>>>>>> and
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066440 - Various changes
>>>>>>>>>>> in testlibrary for JDK-8059613
>>>>>>>>>>> 
>>>>>>>>>>> It introduce a number of tests for segmented code cache, mostly
>>>>>>>>>>> testing thresholds, usage,
>>>>>>>>>>> memory notifications using respective MemoryPoolMXBean(s).
>>>>>>>>>>> There is also a small modification for testlibrary(8066440) used in
>>>>>>>>>>> tests.
>>>>>>>>>>> 
>>>>>>>>>>> Webrev:
>>>>>>>>>>> http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.01/
>>>>>>>>>>> 
>>>>>>>>>>> Testing: manually, using fastdebug nightly build from 2014-12-02
>>>>>>>>>>> 
>>>>>>>>>>> Additional note: this patch assumes
>>>>>>>>>>> "https://bugs.openjdk.java.net/browse/JDK-8065134 -
>>>>>>>>>>> Need WhiteBox::allocateCodeBlob(long, int) method to be implemented"
>>>>>>>>>>> is fixed.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Dmitrij
>>>>>>>> 
>>>>>> 
>>>>> 
>>>>> --
>>>>> Igor
>>>> 
>>> 
>>> --
>>> Igor
>>