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

[Dmitrij Pochepko]

Hi all,

i've corrected diff according to comments.

please see corrected version(also modified according to latest commits)

http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/top/webrev.00
http://cr.openjdk.java.net/~iignatyev/dpochepk/8059613/webrev.03
http://cr.openjdk.java.net/~iignatyev/dpochepk/8066440/webrev.00

a jprt testing job has been created: 
http://scaaa637.us.oracle.com//archive/2014/12/2014-12-12-215231.mephudson.hs-comp

Thanks,
Dmitrij
> Hi Dmitrij,
>
> here are some comments about the tests (not a reviewer).
>
> UsageThresholdNotExceededTest:
> - You can use CodeCacheUtils.MIN_ALLOCATION instead of
> CodeCacheUtils.SEGMENT_SIZE * CodeCacheUtils.MIN_BLOCK_LENGTH.
> - Please add a comment to 'CodeCacheUtils.WB.fullGC()'
>
> UsageThresholdIncreasedTest:
> - Typo "hasn't been hit after allocationg smaller" ->  "allocating"
> - Maybe you should disable code cache sweeping here as well (as you did for the
> UsageThresholdNotExceededTest)
>
> UsageThresholdExceededTest:
> - Calling 'CodeCacheUtils.hitUsageThreshold' may _not_ hit the usage threshold
> if the code cache sweeper is enabled and removes nmethods in between. I think
> you should disable code cache sweeping.
> - Please print information about the counters if the assert is hit in line 66.
>
> ThresholdNotificationsTest:
> - Typo "testing of getUsageThreashold()" ->  "getUsageThreshold()"
> - If not all notifications are received/handled, the test will timeout at line
> 87, right? Maybe you can add a timeout value to 'Utils.waitForCondition' and
> print a useful error message if the timeout is reached.
>
> PoolsIndependenceTest:
> - Typo "testing of getUsageThreashold()" ->  "getUsageThreshold()"
> - Typos "event to be recieved ..." ->  "received" (3x)
>
> PeakUsageTest:
> - Compilation is not disabled. The asserts may fail because a method is compiled
> in between. Even with compilation disabled, adapters and other non-nmethod code
> may be generated and stored in the non-nmethod code heap.
>
> ManagerNamesTest:
> - Typo: "calls in case on segmented code cache" ->  "of segmented"
>
> GetUsageTest:
> - Why do you need 'CodeCacheUtils.WB.deoptimizeAll()'?
>
> General:
> - Is is necessary to have CodeCacheUtils.allocateDefaultSize? In my opinion it
> would be easier to understand if you invoke WB.allocateCodeBlob(...) directly.
>
> Please run the tests on JPRT!
>
> Thanks,
> Tobias
>
> On 04.12.2014 20:13, Dmitrij Pochepko wrote:
>> 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