Isolating tests from general concurrency

[Igor Ignatyev]

> On Mar 19, 2019, at 2:19 PM, gary.adams at oracle.com wrote:
> 
> I have not looked into the current exclusiveAccess.dirs implementation
> but I assume it requires some ordering of tests to ensure that none of the
> tests in the set of excluded directories runs more than one test at a time.
> Or is the locking mechanism local to each of the excluding directories?
despite docs saying that "all tests in the specified directories are run when no other tests in the same directory is being run", jtreg actually prevents concurrent execution of any tests from all the 'exclusiveAccess.dirs'. there is one lock per jtreg's JVM (unless you use -lock, then jtreg also uses fileLock to  guarantee exclusive access for all jtreg instances w/ the same lock).


> 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.

-- Igor
> 
> 
> On 3/19/19 5:06 PM, Jonathan Gibbons wrote:
>> 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
> 
>