RFR: 8360817: [ubsan] zDirector select_worker_threads - outside the range of representable values issue

[Matthias Baesken]

On Tue, 8 Jul 2025 13:31:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the jtreg test
> gc/z/TestMappedCacheHarvest.java
> with ubsan-enabled binaries on macOS aarch64, the following ubsan error is reported :
> 
> 
>  stderr: [/jdk/src/hotspot/share/gc/z/zDirector.cpp:715:33: runtime error: 6.1962e+10 is outside the range of representable values of type 'unsigned int'
>     #0 0x109e368fc in select_worker_threads(ZDirectorStats const&, unsigned int, ZWorkerSelectionType) zDirector.cpp:715
>     #1 0x109e3658c in initial_workers(ZDirectorStats const&, ZWorkerSelectionType) zDirector.cpp:804
>     #2 0x109e35df0 in ZDirector::run_thread() zDirector.cpp:932
>     #3 0x109ecd5f4 in ZThread::run_service() zThread.cpp:28
>     #4 0x108cd1e50 in ConcurrentGCThread::run() concurrentGCThread.cpp:47
>     #5 0x109ce770c in Thread::call_run() thread.cpp:243
>     #6 0x10985be28 in thread_native_entry(Thread*) os_bsd.cpp:599
>     #7 0x19fa8ef90 in _pthread_start+0x84 (libsystem_pthread.dylib:arm64e+0x6f90)
>     #8 0x19fa89d30 in thread_start+0x4 (libsystem_pthread.dylib:arm64e+0x1d30)
> 
> 
> After I added a bit of tracing to `select_worker_threads` it seems we get WAY too high young_to_old_ratio values; in my locally failing example
> young_to_old_ratio:27561965412.478878
> this leads to values out of range of uint and that makes ubsan complain about the uint cast 
> `uint(young_workers * young_to_old_ratio)` .
> We clamp the value anyway to the range 1u to ZOldGCThreads ; so it probably makes sense to avoid such high factors for young_to_old_ratio .

calculate_young_to_old_worker_ratio  returns a  double and this can get (in theory) very large.
and the calculation part of this method

  const double old_vs_young_efficiency_ratio = current_old_bytes_freed_per_gc_time / current_young_bytes_freed_per_gc_time;
  return old_vs_young_efficiency_ratio;

can , depending on what has been freed, get also in practice very large; so it is not really a surprise that we see sometimes  large values.

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

PR Comment: https://git.openjdk.org/jdk/pull/26186#issuecomment-3052188932