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

[Kim Barrett]

On Wed, 3 Mar 2021 18:32:52 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>>> 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.
>> 
>> Well, yesterday I saw to my annoyance that upgrading from g++-7 to g++-9 increased jdk build time by about 30-40%, so I today I am very aware of build times :-/ But you are right of course, its just the hotspot, so maybe its not such a big deal.
>> 
>> I am a bit apprehensive about introducing STL (had to port the STL to outlier platforms in the past and god that was terrible) but mainly I'd like to have a public discussion before starting to use it. And if the majority thinks its okay then I am okay with it too oc. I have been wrong before. Kim said STL quality is very high nowadays.
>
> Thanks for your feedback and discussion. I will refrain from using STL, and use malloc to allocate the array. I presume I should use os::malloc() in this case - please correct me if I am wrong.

re: "there are some configuration and build kludges that were required to make that work." - Thinking about it more, it might be that those kludges were needed even without the jfr uses of the Standard Library.  I think that may have been needed because of uses of the Standard Library by the gtest framework itself.  The jfr tests then took advantage of that support.

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

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