iamadeveloper2026-sketch commented on issue #6029:
URL: https://github.com/apache/jmeter/issues/6029#issuecomment-5633223072
Hi @vlsi and JMeter committers,
Following up on this, I would like to take ownership of #6029 and submit a
PR backed by reproducible benchmarks.
To ensure the PR aligns with JMeter’s architectural direction and merges
cleanly, I've outlined the proposed design, trade-offs, and verification plan
below.
---
### 1. Architectural Strategy: JDK 17 Baseline vs. Java 21 Virtual Threads
JMeter requires Java 17 for compilation/execution, while
`Thread.ofVirtual()` is finalized in Java 21. We can decouple this through one
of two approaches:
| Dimension | Option A: `MethodHandle` Factory (Dynamic Detection) | Option
B: Multi-Release JAR (MRJAR) / SPI |
| :--- | :--- | :--- |
| **Mechanism** | Runtime capability detection via `MethodHandles.Lookup` in
a centralized `ThreadStarterFactory`. | Compile-time separation using Gradle
JVM Toolchains (`src/core/src/main/java21/`) with a `ServiceLoader` SPI. |
| **Build Impact** | **Zero build system changes.** Compiles cleanly under
existing Gradle pipelines. | Modifies Gradle tasks to compile multi-release
bytecode; potential IDE indexing quirks. |
| **Runtime Overhead** | Negligible (`MethodHandle.invokeExact` / invocation
overhead occurs only once per virtual thread spawn). | Zero overhead (native
JVM bytecode invocation). |
| **Fallback** | Gracefully defaults to platform threads if running on JDK <
21 with a clear log warning. | Graceful fallback via SPI default
implementation. |
> **Recommendation:** **Option A** provides the lowest maintenance burden
and cleanest diff, avoiding Gradle MRJAR complications. However, if the PMC
prefers strict type safety via toolchains (Option B), I can structure it
accordingly.
---
### 2. Implementation Scope
1. **Pluggable Thread Spawner (`org.apache.jmeter.threads`):**
- Refactor `ThreadGroup` to replace direct `new Thread(jmeterThread,
...)` instantiation with a delegating thread spawner abstraction.
- Expose the property `jmeter.threads.virtual=true|false` (default:
`false` to guarantee backwards compatibility).
2. **GUI & Test Configuration (`ThreadGroupGui`):**
- Add a `"Use Virtual Threads (Requires Java 21+)"` checkbox.
- If running on `< JDK 21`, the checkbox is disabled with an informative
tooltip.
3. **Concurrency & Lifecycle Guardrails:**
- **`ThreadLocal` Cleanup:** Ensure `JMeterContextService.getContext()`
and thread-local variables are explicitly stripped in `JMeterThread`'s
terminating `finally` block to prevent heap accumulation across tens of
thousands of ephemeral threads.
- **Carrier Thread Pinning Audit:** Profile the standard `HTTPHC4Impl`
and `HTTPJavaImpl` call stacks with `-Djdk.tracePinnedThreads=full` to identify
any blocking I/O occurring inside `synchronized` blocks.
---
### 3. Benchmark & Validation Protocol
As requested, the PR will include comparative data generated against a local
HTTP mock server (Nginx/Netty) measuring:
* **OS Thread Saturation:** Measuring native thread counts via `ps -eLf` at
1,000, 5,000, and 20,000 concurrent simulated users.
* **RSS Memory Footprint:** Tracking native stack and heap allocation via
`jcmd <pid> VM.native_memory baseline/diff`.
* **Throughput & Latency Jitter:** P95/P99 latency stability comparing
Platform vs. Virtual threads under thread saturation.
* **Pinning Telemetry:** Output of `-Djdk.tracePinnedThreads=full`
confirming unhindered unmounting during I/O wait.
---
### Feedback Requested
1. Do you have a strong preference between **Option A (MethodHandle
factory)** vs. **Option B (MRJAR/SPI)** for the build?
2. Are there specific legacy samplers/protocols you would like explicitly
audited for carrier pinning beyond the core HTTP samplers?
Once we align on the JDK decoupling preference, I will finalize the branch
and open the draft PR.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
