JDK-8264624 : change the guarantee() calls added by JDK-8264123 to assert() calls
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2021-04-01
  • Updated: 2025-02-25
  • Resolved: 2021-05-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17
17 b25Fixed
Related Reports
Relates :  
JDK-8264123 - add ThreadsList.is_valid() support
Relates :  
JDK-8307970 - Thread.start is slow with large number of threads
Relates :  
JDK-8350616 - Skip ValidateHazardPtrsClosure in non-debug builds
Description
Allow the guarantee() calls to bake for 4-6 weeks before converting
to assert() calls. [~rehn] recommends trying to measure the cost of
having those guarantee() calls in the 'release' bits before changing
them to assert() calls since they are a useful diagnostic tool.
Comments
Changeset: 591b0c3a Author: Daniel D. Daugherty <dcubed@openjdk.org> Date: 2021-05-28 16:24:04 +0000 URL: https://git.openjdk.java.net/jdk/commit/591b0c3a463e07d2ec26047f0e61855cbfde13b6
28-05-2021
We have yet to see any of these guarantee() calls fire in any release, fastdebug, or slowdebug testing that has been done since JDK-8264123 was integrated in JDK17-B17. For simplicity, I'm going to go ahead and change all of the guarantee() calls added by JDK-8264123 into assert() calls and make ThreadsList::is_valid() only available in an ASSERT build. If we need this code in release builds in the future, we can always revert this fix.
28-05-2021
I looked a bit at the code, I only saw one concern: void ThreadsSMRSupport::free_list(ThreadsList* threads) { assert_locked_or_safepoint(Threads_lock); .... ValidateHazardPtrsClosure validate_cl; threads_do(&validate_cl); .... Here we do an extra scan with Threads_lock held, with thousands of short lived threads I think it does make a difference.
14-04-2021