[amarziali]

What Does This Do

OpenJDK 25 schedules virtual-thread timeout callbacks through ForkJoinPool. Our scheduled-task instrumentation captures the creating request context for these callbacks, even though they only wake the virtual thread and do not consume that context.

This PR excludes JDK-owned VirtualThread lambdas from context capture. This avoids unnecessary continuation allocation and request-context retention while preserving propagation for application-scheduled tasks.

Validation includes a diagnostic test checking capture absence while a virtual thread is parked, FJP scheduling tests checking application context propagation, and packaged-agent cold-start smoke tests checking parking and resumption with virtual-thread instrumentation both enabled and disabled. The FJP instrumentation independently preloads its context-filtering helper.

The exclusion uses the generated java.lang.VirtualThread$$Lambda/ class-name prefix and covers all lambdas owned by VirtualThread. It depends on JDK implementation details. Validation was performed on HotSpot/OpenJDK 25 with the default virtual-thread scheduler. The OpenJ9 lambda metafactory source uses the same naming mechanism, but OpenJ9 runtime compatibility has not been tested. Revisit the exclusion if lambda naming or responsibilities change. Custom virtual-thread schedulers are outside the demonstrated coverage.

Motivation

Additional Notes

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Once approved, use merge queue to merge the PR

Jira ticket: [PROJ-IDENT]

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-13T13:16:39.633080Z	080ffc2	PR opened
🔒 Security Review	✅ Completed 2026-10-13T13:17:14.289635Z	080ffc2	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[datadog-prod-us1-5]

More details

The exclusion targets JDK virtual-thread callbacks while preserving context capture for application-scheduled Runnable and Callable tasks. The completed static review found no actionable correctness issue; runtime behavior remains unverified.

Was this helpful? React 👍 or 👎

_{Open Bits AI session}

_{🤖 Bits Code Review · Commit 080ffc2}

[dd-octo-sts]

🟢 Java Benchmark SLOs — All performance SLOs passed

Suite	Status
Startup	🟢 pass

SLO thresholds are defined here based on automatically generated metrics. A warning is raised when results are within 5% of the threshold.

PR vs. master results

Scenario	Candidate	master	Δ (95% CI of mean)
startup:insecure-bank:iast:Agent	13.97 s	13.99 s	[-1.0%; +0.6%] (no difference)
startup:insecure-bank:tracing:Agent	12.87 s	12.99 s	[-1.7%; -0.2%] (maybe better)
startup:petclinic:appsec:Agent	16.71 s	16.94 s	[-5.7%; +2.9%] (no difference)
startup:petclinic:iast:Agent	16.90 s	16.92 s	[-1.1%; +0.8%] (no difference)
startup:petclinic:profiling:Agent	16.08 s	16.59 s	[-7.3%; +1.1%] (no difference)
startup:petclinic:sca:Agent	17.06 s	16.54 s	[-1.3%; +7.6%] (no difference)
startup:petclinic:tracing:Agent	16.13 s	16.03 s	[-0.0%; +1.3%] (no difference)

Commit: 620972d0 · CI Pipeline · Benchmarking Platform UI

---

Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion.

[PerfectSlayer]

The exclusion uses the generated java.lang.VirtualThread$$Lambda/ class-name prefix. This depends on JDK implementation details and covers all lambdas owned by VirtualThread, so it should be revisited if their responsibilities or naming change.

That might bite us later… No other way than relying on JDK-specific and all lambdas?

[bric3]

I'll just rename the PR title as it lands as commit message.

About the precise type matching I don;t see another way at this time.

[dougqh]

Overall, this looks good to me.
Claude had a couple suggestions that I think would be good to address.
I also think it would make more sense to label that as bug:fix or performance rather than feature.

[amarziali]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-10-14 07:21:13 UTC ℹ️ Start processing command /merge

---

2026-10-14 07:21:17 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-10-14 07:37:45 UTC ❌ MergeQueue: The build pipeline contains failing jobs for this merge request

Build pipeline has failing jobs for 902289e:

• check_build_src

⚠️ Do NOT retry failed jobs directly (why?).

What to do next?

• Investigate the failures and when ready, re-add your pull request to the queue!
• If your PR checks are green, try to rebase/merge. It might be because the CI run is a bit old.
• Any question, go check the FAQ.

Details

Since those jobs are not marked as being allowed to fail, the pipeline will most likely fail.
Therefore, and to allow other builds to be processed, this merge request has been rejected and the pipeline got canceled.

[amarziali]

/merge

[gh-worker-devflow-routing-ef8351]

View all feedbacks in Devflow UI.

2026-10-14 08:35:58 UTC ℹ️ Start processing command /merge

---

2026-10-14 08:36:02 UTC ℹ️ MergeQueue: pull request added to the queue

The expected merge time in master is approximately 1h (p90).

---

2026-10-14 09:30:24 UTC ℹ️ MergeQueue: This merge request was merged