RFR: JDK-8214097: Rework thread initialization and teardown logic

[Kim Barrett]

> On Dec 26, 2018, at 11:41 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Kim,
> 
> On 27/12/2018 10:18 am, Kim Barrett wrote:
>>> On Dec 19, 2018, at 4:21 PM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Following on from the preliminary RFR:
>>> 
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-December/035737.html
>>> 
>>> I've merged with Kim's changes from 8215097.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214097
>>> Webrev: http://cr.openjdk.java.net/~dholmes/8214097/webrev.v2/
>> Looks good.
> 
>> test/hotspot/gtest/threadHelper.inline.hpp
>> These JavaTestThreads are weird, and it seems like it would be better
>> if they were more normal.  But maybe that can be done in a later
>> cleanup.  The new, improved, life-cycle management might make that
>> easier.
> 
> I don't think they really can be "normal" JavaThreads as that requires they get a java.lang.Thread object and all the associated logic that goes along with that. I know little of the gtest mechanism and have no idea how much of the VM is initialized when these gtests run. Anyway this is out of scope for this change.

The gtests that use these threads are all TEST_VM, e.g. they require a fully initialized VM before the test can be run.

I’m not sure why they were kind of wedged in the way they are, and looking at what needs to be
done to make that work (and perhaps future work too), I think making them normal would be a
good thing, or perhaps even a necessary thing eventually.  But agree it’s out of scope for the
change under review.  File a followup RFE?