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

[Thomas Stuefe]

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

>> On a question: where does it allocate memory for 't' ? Are the elements leaked here?
>> The vector will allocate and free the memory for the containers (the memory containing pointers to UnitTestThread). 
>> 
>> As for the UnitTestThread objects/instances themselves:
>> - JavaTestThread. I checked couple of other examples of uses of JavaTestThread (test_symbolTable.cpp and oops/test_markWord.cpp), and neither is calling explicit delete on the objects of this type
>> - I presume the thread will free its resources once it exits (and we wait for done semafore to ensure this)
>> - adding code “delete t[i]” results in crash, presuming due to freeing an already released memory
>> 
>> Hence, I believe, no changes needed to this code to free resources.
>
>> Regarding the STL question, I think using std in a limited fashion in the tests seems ok before we start allowing it in the main sources, despite where Misha pointed out it already exists. It's going to be allowed pretty soon anyway.
> 
> Really? I recently had a private discussion with Kim Barret about this and understood that this is a contentious point. I was hoping we would have a public discussion about this before deciding on this. My fears are increased build times (which seem to get worse and worse) and stability- and compiler issues. I am not completely against it, but I'm a bit of a burned child wrt to STL.

> One question about this: where does it allocate memory for 't' ? Are the elements leaked here?

Backing buffer for vector lives in C-heap. Its a dynamically growing array, basically like our GrowableArray. Only its not under our control and we cannot easily debug it if something goes wrong (take a look at the STL sources, they are not easy to understand). And it sidesteps our own os::malloc, so we cannot account it, and our guards won't work.

Personally I would like to keep the test harness as simple stupid as possible, to avoid interfering with the actual test. Especially with tests which test memory allocation. I know that is a vague reason, but I also cannot find a bit advantage in using std::vector, compared with a simple calloced array. We dont need the dynamically-growing part here, we know right upfront how many threads we start, so its really a fixed sized array.

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

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