Keep old names as part of the RenamingExecutor to debug big cached thread pools

[wi11dey]

Before this PR

When using a NylonExecutor to wrap a cached threadpool with a name, when the task would finish, it would rename the thread back to the original name, usually something like shared-1038. Many of our cached threadpools actually just share one big shared threadpool. When looking at JFRs or jstacks, it's common to see hundreds of shared-18034 threads which doesn't provide much info on what task caused the cached threadpool to accumulate threads after the task has finished. This is especially a problem if there is a large number of short-lived but concurrent tasks which cause the threadpool to expand, but doesn't leave a trace of what the task that caused the threadpool to expand so large.

After this PR

Now, threads will be renamed to shared-130483-was-taskname after the task has finished for observability and debugging. We limit to at most one -was- suffix to avoid accumulating more and more old task names in the thread names.

Possible downsides?

I don't think there are any. The regex split is precompiled and should be fast

[changelog-app]

Generate changelog in changelog/@unreleased

Type (Select exactly one)

• Feature (Adding new functionality)
• Improvement (Improving existing functionality)
• Fix (Fixing an issue with existing functionality)
• Break (Creating a new major version by breaking public APIs)
• Deprecation (Removing functionality in a non-breaking way)
• Migration (Automatically moving data/functionality to a new system)

Description

Keep old names as part of the RenamingExecutor to debug big cached thread pools

Check the box to generate changelog(s)

• Generate changelog entry

[changelog-app]

✅ Successfully generated changelog entry!

What happened?

Your changelog entries have been stored in the database as part of our migration to ChangelogV3.

Need to regenerate?

Simply interact with the changelog bot comment again to regenerate these entries.

Outdated

[pkoenig10]

I don't think this is a good idea.

I don't think we should be leaking information about tasks after the task has completed.

And the information here isn't really useful. If the goal is to determine what executor caused a thread to be created, this doesn't tell you that, since the name will be replaced as soon as this thread is reused for another task. So, seeing a particular -was- name doesn't actually allow you make any reliable conclusions.

[bjlaub]

Approving for release candidate only.

Invalidated by push of 3b3d13d