RFR: 8213269: convert test/hotspot/jtreg/runtime/memory/RunUnitTestsConcurrently to gtest [v6]

[Coleen Phillimore]

On Wed, 3 Mar 2021 05:43:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Using regular brackets in initializer list instead of curly brackets
>
> Hi Misha,
> 
>> Hi Thomas,
>> I do most of my JDK work in Java, hence may have missed knowing the restriction of using STL.
>> I wonder if this restriction is only for source code, and not the tests. I did a quick search under "test/hotspot/gtest", and found many uses of std::, including the data structures. For instance, jfr/test_networkUtilization.cpp uses std::map, std::list and std::vector.
> 
> See my answer to Coleen. I think using the STL would have a number of repercussions which should be discussed before doing this step. 
> 
> About the patch itself:
> 
> I am not sure moving more and more test control down into gtest is a good thing. gtests have mostly be single threaded until now and could be run within a make. AFAIU gtests offer way less run control than jtreg does, e.g. you cannot disable the test without recompiling the hotspot (there is no ProblemList equivalent for gtest), you have no test groupings (e.g. to separate stress tests which need a whole machine for themselves) etc. Also, we will duplicate more and more thread control in C++.
> 
> I understand the wish to remove the test coding from the hotspot implementation. Its so ugly and should not live there. But just moving them to separate implementation files, possibly within a clearly marked "tests" folder, would be a first good step.
> 
> I will not block this if you have decided to go this way. Just wanted to understand the direction you guys plan to go with gtests in the future. If they get more complex and powerful we may need more control, eg the possibility to problemlist tests.
> 
> Cheers, Thomas

Moving these tests out of our source code is a good change.  We already have a couple multithreaded tests in gtest, and adding this one isn't going to make the gtests unreliable.  For future multithreaded tests, it makes sense to make them jtreg tests so that we can control their execution.  So I'd like to see this PR integrated, with suggested changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2436