Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8365317

ZGC: Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P4 P4
    • 26
    • 21, 25
    • hotspot
    • gc
    • b11

      Setting ZYoungGCThreads lower than ZOldGCThreads may result in a crash, for example using -XX:ZYoungGCThreads=4 and -XX:ZOldGCThreads=8. The problem is in select_worker_threads() in zDirector.cpp, where the number of young threads may be set to the number of old threads, in an attempt to speed up the young collection so that the old collection can begin faster in a major collection. If the number of old threads exceed the maximum number of young threads, i.e. ZYoungGCThreads, a crash may occur. In a release build, the crash is likely due to writing out-of-bounds and then using the corresponding memory at a later point in the _workers array, when creating more than _max_workers number of threads (which will happen if we try to create more threads than ZYoungGCThreads).

      In a slowdebug build, this combination is likely to hit an assert when adjusting the number of threads.

      # A fatal error has been detected by the Java Runtime Environment:
      #
      # Internal Error (c:\cygwin64\home\jsikstro\jdk\open\src\hotspot\share\gc\shared\workerThread.cpp:118), pid=16464, tid=14648
      # assert(num_workers > 0 && num_workers <= _max_workers) failed: Invalid number of active workers 7 (should be 1-4)
      #
      # JRE version: Java(TM) SE Runtime Environment (26.0) (slowdebug build 26-internal-2025-08-06-1532495.jsikstro...)
      # Java VM: Java HotSpot(TM) 64-Bit Server VM (slowdebug 26-internal-2025-08-06-1532495.jsikstro..., mixed mode, tiered, compressed class ptrs, z gc, windows-amd64)
      # Problematic frame:
      # V [jvm.dll+0x146eccb] WorkerThreads::set_active_workers+0x3b

      In a release build, crashes occur intermittently, and I have only been able to reproduce while also enabling JFR using -XX:StartFlightRecording. My theory is that JFR walks created threads, which will cause it to read out-of-bounds in the _workers list in WorkerThreads.

      #
      # A fatal error has been detected by the Java Runtime Environment:
      #
      # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000000000000, pid=8908, tid=16592
      #
      # JRE version: Java(TM) SE Runtime Environment (26.0) (build 26-internal-2025-08-06-1502179.jsikstro...)
      # Java VM: Java HotSpot(TM) 64-Bit Server VM (26-internal-2025-08-06-1502179.jsikstro..., mixed mode, tiered, compressed class ptrs, z gc, windows-amd64)
      # Problematic frame:
      # V [jvm.dll+0x7a3936] OSThreadBase::print_on+0x16

            jsikstro Joel Sikström
            jsikstro Joel Sikström
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: