RFR: 8292679: Simplify thread creation in gtest and port 2 tests to new way

[Johan Sjölén]

On Tue, 23 Aug 2022 07:29:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>One simpler, more pragmatic way would be for the thread group to give each started thread a numeric id. Most of the cases I can think of would be happy with that, using the id inside the thread function to control behavior.

That might be sufficient. Looking through the test cases, they're either too complex for me to take the time to understand for this discussion, or would work OK with this kind of id. I'm thinking for N threads, each threads gets a unique id in the range `[0,N)`, are we thinking the same thing?

>The ability to start with the number of threads dictated at runtime, depending on runtime conditions. The ability to reuse the same TTG in different subtests with different thread numbers without template bloat.

There's probably no significant gain to be had in re-using the same TTG in different subtests, but I see the value of minimizing compilation times by not having several monomorphizations depending on N.

>Actually, the same argument goes for F. This design still requires us to use the same thread function for all threads. For cases where you want to have multiple different thread functions, you would still end up with some sort of switch inside the thread function. If F were a runtime thing, you could do something like this:

That's flexible, but not easier to understand. Suddenly, several `doit()` and several `join()`s are viable, it makes the semantics of TTG way more complicated. Simple tests are preferable, I'd keep `F` if it meant that we *can't* add two different functors to a TTG.

We *can* get rid of `F`, as so:


#include <functional>

template<typename S>
class BasicTestThread : public JavaTestThread {
  std::function<void(Thread*, S)> f;
};


Unfortunately `std::function` is a no go, but it does show an enticing way forward. It would be useful in many places of Hotspot, probably having a real build time improvement.


Here's my plan:

- Move N out from being a template parameter to a constructor argument
- Try to remove S and instead use a numeric id, see how the two solutions differ for these test cases. If it's nice, I'll also remove S (and therefore also state generator, for example).
- I'm keeping F, no changes there.

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

PR: https://git.openjdk.org/jdk/pull/9962