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

[Matthias Baesken]

On Thu, 10 Jul 2025 07:12:54 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 .
>
> Thanks for the review Lucy !
> May I get a second review ?

> @MBaesken Thanks for the explanation. That's the mathematics. What does it tell us about the gc workload? Is it that the application mostly creates long-lived objects which all get promoted before they eventually can be collected?
> 
> Maybe this is out-of-scope for such a small fix.

The ZGC people can probably comment on this.
Not sure what is 'normal'  / usual there with ZGC.

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

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