Isolating tests from general concurrency

Igor Ignatyev igor.ignatyev at oracle.com
Wed Mar 20 03:37:51 UTC 2019



> On Mar 19, 2019, at 7:52 PM, Jonathan Gibbons <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
> 



More information about the jtreg-dev mailing list