RFR: 8229517: Support for optional asynchronous/buffered logging [v11]

[Xin Liu]

On Fri, 7 May 2021 13:11:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I tried but I found it's  difficult not to use LogTestFixture here for async logging tests.
>>  
>> The constructor and destructor of LogTestFixture help me do the chores. 
>> Without them, I can't use this set up function.
>>   `set_log_config(TestLogFileName, "logging=debug");`
>
> I see what you mean. I have thought about this some more. 
> 
> Unfortunately this requires you to be able to initialize and shutdown async logging at arbitrary times in the middle of VM life. Which normally would not be necessary. Not a big deal, but here is a slightly different proposal (and its just a proposal, I leave it up to you if you take this):
> 
> Instead of starting up and shutting down async logging at the start/end of a test (or, instead of the TEST_OTHER_VM proposal I did earlier), how about this:
> 
> 1) Change your tests to not modify logging options. No fixture, no setup/teardown, no setup_logging(). Leave the tests passive: In the tests, you just react on those options (eg skipping AsyncLogTests if async logging is disabled)
> 2) Instead, you hand in all logging options you need from the outside via command line into the gtestLauncher. 
> 3) rename your tests to start with "Log..." like all other UL gtests. 
> 4) Then, add a gtest run configuration to the gtest jtreg wrapper: add a configuration with async=true and lots of logging. Limit on this command line the gtests to only run UL gtests ('--gtest_filter=Log*' )
> 
> This is actually very easy, I have done this for large page tests and metaspace test, among other things. See `test/hotspot/jtreg/gtest/LargePageGtests.java` or `test/hotspot/jtreg/gtest/MetaspaceGtests.java`. 
> 
> The advantage would be:
> - no need to fiddle with log options in your tests, and to reinstate them at teardown
> - no danger of accidentally disturbing other neighboring gtests, if yours is executed in parallel to others (we don't do this today but its possible).
> - You execute all logging gtests - not only yours - with both async=false and async=true, and this is a better test coverage. This would be a nice stress test for async logging.
> 
> I understand if you don't want to do this now. This would be a fine future RFE (since actually, it should be done for all UL tests, not only yours).

Interesting,  I don't know that we can trigger gtest from Jtreg with JVM options.  Nifty!

 * @run main/native GTestWrapper --gtest_filter=metaspace* -XX:MetaspaceReclaimPolicy=none

> Unfortunately this requires you to be able to initialize and shutdown async logging at arbitrary times in the middle of VM life. Which normally would not be necessary. 
Yes, I don't like that. I tried to delete LogAsyncFlusher::terminate() several times. None of them succeed. 
I am fine we don't reclaim 
I tried to make use Threads::destroy_vm() -> LogConfiguration::finalize()

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

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