Isolating tests from general concurrency

Jonathan Gibbons jonathan.gibbons at oracle.com
Tue Mar 19 21:06:27 UTC 2019


Igor,

What you suggest is not easy given the way jtreg currently runs tests.  
I'm not saying we can't support "nonconcurrent" tests, but I doubt that 
we would do it as you describe.

-- Jon

On 3/19/19 2:03 PM, Igor Ignatyev wrote:
> Jon,
>
> in vm-testbase we used to have 'nonconcurrent' k/w to get concurrency=1 for specific tests. the keyword was recognized by test harness, and all "nonconcurrent" tests were moved to the end of execution queue and started only after all "concurrent" tests finish their execution. although this would have a side effect on test execution order, I don't think it should be a problem for us as AFAIK jtreg doesn't guarantee any particular order, and the solution is nice and simple and it shouldn't be hard to implement the same/similar logic in jtreg.
>
> -- Igor
>
> (sorry if it creates another email thread, I subscribed to the list after the discussion had started)
> On 3/19/19 12:56 PM, Jonathan Gibbons wrote:
>> On 3/19/19 12:03 PM, Gary Adams wrote:
>>> A recent question came up about how the exclusiveAccess.dirs property
>>> was being used to
>>> prevent concurrent tests from using some critical resource. It appears
>>> that some of
>>> the hotspot/jtreg/vmTestbase tests were setting the property assuming
>>> they would get
>>> a concurrency=1 type of behavior.
>>>
>>> I'd like to start the discussion about how the current feature works
>>> and see
>>> if a new feature might be appropriate for other related use cases.
>> The feature was originally created for tests that needed exclusive access to specific system resources: specifically, fixed ports in RMI/networking tests. To some extent, it was a quick stop-gap measure, to avoid having to rewrite those tests in short order to use dynamically allocated ports. The need for "concurrency=1" behavior is new/different. Previously, all tests wanting exclusive access had to opt-in to the feature.  To support "concurrency=1", there's an implicit need to check any interlock on all tests that don't request "concurrency=1".
>> -- Jon


More information about the jtreg-dev mailing list