RFR: 8349927: Waiting for compiler termination delays shutdown for 10+ ms

David Holmes dholmes at openjdk.org
Thu Feb 13 05:37:10 UTC 2025


On Wed, 12 Feb 2025 19:13:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for extended description. This PR reworks the shutdown waiting mechanism in three ways: 
>  1. Use exponential backoff with very small wait time at the start, to catch compiler threads earlier.
>  2. Avoid timed-wait on Monitor, when a sleep would suffice.
>  3. Track the time accurately, so we are not at the mercy of sleep/wait accuracy.
> 
> I originally found this issue when studying Leyden performance, but it affects mainline in the same way. For example, JavacBenchApp from Leyden shows we consistently save ~10ms of round-trip time:
> 
> 
> Benchmark 1: build/linux-x86_64-server-release/images/jdk/bin/java -Xmx512m -Xms512m -XX:+UseParallelGC \
>  -cp JavacBenchApp.jar JavacBenchApp 1 1
> 
> # Before
>   Time (mean ± σ):     495.4 ms ±   2.4 ms    [User: 1321.2 ms, System: 110.4 ms]
>   Range (min … max):   489.8 ms … 502.6 ms    100 runs
> 
> # After
>   Time (mean ± σ):     485.4 ms ±   2.7 ms    [User: 1318.9 ms, System: 110.3 ms]
>   Range (min … max):   479.8 ms … 494.3 ms    100 runs
> 
> 
> Additional testing:
>  - [ ] Linux x86_64 server fastdebug, `tier1`
>  - [ ] Linux AArch64 server fastdebug, `all`

Looks good and works in nicely with user thread changes. One suggested comment addition as I had to check the user-thread wait-time couldn't exceed the compiler thread wait-time.

Thanks

src/hotspot/share/runtime/vmOperations.cpp line 522:

> 520: 
> 521:   // Deadline for user threads in native code.
> 522:   // User-settable flag counts "attempts" in 10ms units.

Suggestion:

  // User-settable flag counts "attempts" in 10ms units, to a maximum of 10s.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23593#pullrequestreview-2613889752
PR Review Comment: https://git.openjdk.org/jdk/pull/23593#discussion_r1953838705


More information about the hotspot-runtime-dev mailing list