RFR: 8263567: gtests don't terminate the VM safely

[David Holmes]

On Wed, 4 Aug 2021 05:55:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
> 
> Testing:
>   - manual instrumentation to check all JVM construction and then deletion during gtest runs
>   - local gtest testing
>   - tiers 1-3 gtest testing
> 
> Thanks,
> David

Hi Thomas,

On 4/08/2021 5:22 pm, Thomas Stuefe wrote:
> On Wed, 4 Aug 2021 05:55:11 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Please review this fix to shutdown cleanly any JVMs created by gtests that aren't aborted.
>>
>> Testing:
>>    - manual instrumentation to check all JVM construction and then deletion during gtest runs
>>    - local gtest testing
>>    - tiers 1-3 gtest testing
>>
>> Thanks,
>> David
> 
> Hi David,
> 
> looks good, small remarks inline and one general remark here:
Thanks for taking a look at this. Sorry for the delayed follow-up. 
> I wonder whether we should not just always initialize the VM at launch and destroy it after finish, regardless of the tests we run. We even could abolish TEST and just always do TEST_VM.
> 
> While in theory TEST (without _VM) is a good idea because we save time on the VM initialization, in practice
> 1) usually one just runs always the full suite, or a subset of it which includes TEST_VM tests, so most of the time we pay for VM init anyway.
> 2) tests are done using copy+paste and use TEST_VM unnecessarily. OTOH I also already had TEST tests that needed VM stuff. I mean that maintaining the correct designation for the tests is cumbersome and error-prone.
> 3) The _VM flexibility, tied to order and selection of tests, means the time VM initialization happens is unpredictable, which makes analysis more difficult and behavior sometimes surprising.
> 
> We could simplify all this and the runner code by just unconditionally initializing the VM at start of the gtestlauncher. I think the benefits of differentiating between TEST and TEST_VM are slim in practice.

That may be true but I don't think it is for this issue/PR to try and address that. I can imagine that some basic TEST() cases assume a pristine environment with no chance of any external perturbation (such as by an initialized and thus operating VM). That said with the way tests get interleaved depending on exactly how you run them, it isn't clear that a TEST() may not run when the VM is already initialized anyway!

Thanks,
David

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

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