JDK-8256382 : Use try_lock for hs_err EventLog printing
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-11-16
  • Updated: 2020-12-07
  • Resolved: 2020-12-02
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 16
16 b27Fixed
Related Reports
Blocks :  
Description
The EventLog locks are taken when the hs_err files are generated. Since crashes and asserts can occur when other locks are held, this can cause lock reordering problems if the held locks also are low-rank locks. There's no way to solve this if blocking locks are taken.

I hit this problem when investigating making the GCLogPrecious lock use the lowest lock rank (same as EventLog).

Both GCLogPrecious and EventLog are considered "leaf" locks. No other locks should be taken when those locks are taken. However, if we crash in either of these sub-systems, there will be a lock-reordering error message in the hs_err file, and the rest of the logged info is skipped in the currently logged section.

The proposal is to use try_lock_without_range_check and only log information if the lock could be acquired without blocking. This relies on the new try_lock_without_range_check function from JDK-8255678.
Comments
Changeset: 1fd0ea70 Author: Stefan Karlsson <stefank@openjdk.org> Date: 2020-12-02 12:28:10 +0000 URL: https://git.openjdk.java.net/jdk/commit/1fd0ea70
02-12-2020