[Feature] Upgrade to JDK/JVM25 to adopt ZGC and VirtualThread

[wu-sheng]

Search before asking

• I had searched in the issues and found no similar feature requirement.

Description

With the recent 10.3 update, we have optimized the thread pool performance a lot -- from 800 threads to ~150 threads.

Use case

With JDK/JRE21 new features, virtual thread and ZGC have potential advantages to optimize OAP performance.
We should be able to consider that.

Related issues

No response

Are you willing to submit a pull request to implement this on your own?

• Yes I am willing to submit a pull request on my own!

Code of Conduct

• I agree to follow this project's Code of Conduct

[wu-sheng]

@wankai123 I just checked the JDK LTS plan, JDK 21 and 25 are LTS. We should consider these.

[peachisai]

Will the java agent support these LTS versions?

[wu-sheng]

This proposal is mostly around adopting virtual thread of newer JDK.
Agent should support new versions, do you have plan to work on that?

[wu-sheng]

#13703 managed all threads in the OAP. VirtualThread thing will focus on gRPC/HTTP server thread factory.

[wu-sheng]

I have been working on the virtual thread support for OAP server. Here is the summary of planned changes (PR coming soon):

Virtual Thread Support for gRPC & HTTP Servers (JDK 25+)

Approach: Runtime reflection-based detection — zero compile-time dependency on JDK 25 APIs, fully backward compatible with JDK 11/17/21.

Why JDK 25 (not 21)? JDK 21-23 has a critical synchronized pinning issue (JEP 491 fix lands in JDK 24). JDK 24 is non-LTS (6-month support). JDK 25 LTS (September 2025) is the first production-ready LTS with the fix.

What changes:

Thread Pool	JDK < 25 (unchanged)	JDK 25+
gRPC handler (core-grpc, receiver-grpc, als-grpc, ebpf-grpc)	Cached platform threads (unbounded)	Virtual threads (per-task)
HTTP blocking (core-http, receiver-http, promql-http, logql-http, zipkin-query-http, zipkin-http, firehose-http)	Cached platform threads (max 200/server)	Virtual threads (per-task)
Netty/Armeria I/O event loops	Platform threads	Unchanged

Key implementation details:

• New VirtualThreads utility class handles all reflection-based detection and executor creation
• Custom VirtualThreadScheduledExecutor wraps virtual threads as ScheduledExecutorService for Armeria compatibility
• All virtual threads are named (vt:{poolName}-{number}) for monitoring/debugging
• Disable via SW_VIRTUAL_THREADS_ENABLED=false environment variable
• Default Docker image upgraded from JDK 11 to JDK 25; JDK 11/17/21 variants still available

This covers the virtual thread part of this issue. ZGC adoption can be addressed separately (JVM flag configuration).

cc @kezhenxu94 @wankai123 FYI