8364004: Add an option for delayed crash tests

[tstuefe]

Pretty simple small addition to make -XX:ErrorHandlerTest work with an optional delay. This is a preparatory patch for some future planned refinements/additions to the error handler tests. It makes it possible to let the JVM warm up for a second or three, then to crash, in order to then observe an error log from a warmed-up JVM.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8364004: Add an option for delayed crash tests (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/26453/head:pull/26453
$ git checkout pull/26453

Update a local copy of the PR:
$ git checkout pull/26453
$ git pull https://git.openjdk.org/jdk.git pull/26453/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26453

View PR using the GUI difftool:
$ git pr show -t 26453

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/26453.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back stuefe! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@tstuefe The following label will be automatically applied to this pull request:

• hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (2f31b662)

[dholmes-ora]

Not sure I see the point of this being in the VM. First you are now going to trigger crashes in the WatcherThread instead of the main thread - not sure if that changes what you want to see. Second seems easier to just have a WhiteBox test that triggers different kinds of crashes after initialization.

If you want to trigger crashes at arbitrary times during initialization then I have no doubt you will find issues with crash reporting and it will be totally timing related and would make the test quite unstable.

[tstuefe]

@dholmes-ora You are right. I am closing this one in favor of the approach you suggested in JBS.