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

[Coleen Phillimore]

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

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

Okay so you're right that we can't account in NMT and with our malloc guards for the memory that is allocated with std::vector, so I'm convinced that Misha should change this.  Hopefully we can figure out how to make std::vector work in the future, because Misha's 2 lines for it look quite nice.
Do you think using std:: would increase build times? My suspicion is that the Access barrier templates are to blame, but building hotspot is a fraction of building the whole jdk, which does seem to take a long time.

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

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