8369692: JFR: Don't record thread metadata in case jdk.ThreadStart is disabled

[krk]

Before

File size: 0.84 MB
Scrubbed size: 0.82 MB
Waste: 2.73%

After

File size: 0.80 MB
Scrubbed size: 0.78 MB
Waste: 3.40%

File size decreases when ThreadStart and ThreadEnd events are disabled.

---

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-8369692: JFR: Don't record thread metadata in case jdk.ThreadStart is disabled (Enhancement - P4)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 28222

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back krk! 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]

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

• hotspot-jfr

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 (ad86a925)

[mgronlun]

This is not correct, because now thread information will be missing for other events.

Solving this proper would involve introducing a lazy write scheme of thread metadata on first use, but this can have other impacts, like the need to check for every event.

[krk]

Instead of checking for every event, we could set a flag unconditionally and check on thread start/end.

What if we add a volatile bool _has_emitted_events to JfrThreadLocal and:

• Set the flag when any event with T::hasThread is written (unconditional store)
• At thread start/exit: write the checkpoint if EventThreadStart/End::is_enabled() || has_emitted_events()
• Clear the flag after writing checkpoint

What do you think?

[mgronlun]

Instead of checking for every event, we could set a flag unconditionally and check on thread start/end.

What if we add a volatile bool _has_emitted_events to JfrThreadLocal and:

* Set the flag when any event with `T::hasThread` is written (unconditional store)

* At thread start/exit: write the checkpoint if `EventThreadStart/End::is_enabled() || has_emitted_events()`

* Clear the flag after writing checkpoint

What do you think?

The checkpoint must be in place before a T::hasThread native event is written.
Also, any event generated in Java must have checkpoint information in place already.