Isolating tests from general concurrency

Jonathan Gibbons jonathan.gibbons at oracle.com
Wed Mar 20 03:43:34 UTC 2019


On 3/19/19 8:37 PM, Igor Ignatyev wrote:
>
>
>> On Mar 19, 2019, at 7:52 PM, Jonathan Gibbons 
>> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>>
>>
>> On 3/19/19 2:34 PM, Igor Ignatyev wrote:
>>>> How is the queue managed when normally concurrent tests are launched?
>>>> Instead of waiting til the end, a test requiring concurrency=1 could simply wait
>>>> for the queue to drain before being launched.
>>> I'll let Jon to comment on the current implementation. but waiting for the queue to drain each time we meet 'nonconcurrent' test will add multiple serialization points and might have measurable impact on overall execution time.
>>
>> Currently, jtreg uses the test runner mechanism provided by the 
>> underlying JT Harness framework.   Changing that will be a Very Big Deal.
>>
>> How many nonconcurrent tests are there, out of how many tests total?
>>
> if we count all current "exclusiveAccess" as nonconcurrent, we will 
> get less than 4% of all tests, most of them are in hotspot test 
> suites, and in hotspot test suites nonconcurrent tests make up 8%.
>
> I prototyped smth similar to that Gary suggested in the dirtiest 
> possible way[1] using read-write lock: nonconcurrent tests acquire a 
> write lock, while other tests acquire read lock; will use it to 
> measure performance impact for different test groups/directories later 
> this week.
>
> [1] 
> http://cr.openjdk.java.net/~iignatyev//jtreg/rwLock/webrev.00/index.html
>>
>> -- Jon
>>
>
Sounds good.

I'll also talk to Dmitry Bessonov about what's available in JT Harness.

-- Jon



More information about the jtreg-dev mailing list