JDK-8222841 : Incorrect static call stub interactions with class unloading
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-04-23
  • Updated: 2022-11-07
  • Resolved: 2019-05-14
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 13
13 b21Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Static call stubs are cleared in debug builds before an assert checking for dead metadata. The reason is that the static call stub has metadata, and it complains about dead metadata being left after inline cache cleaning of is_alive nmethods.

...except class redefinition looks at this metadata to determine if there is old metadata in subsequent safepoints, and they could have been unloaded then. Ouch. So maybe we shouldn't squelch that assert.

...and with concurrent class unloading, we can't just clear the call stub of a concurrently running JavaThread; they can get stuck in an infinite loop.

All things considered, clearing static call stubs when unloading the code cache seems like a bad idea.
Comments
URL: http://hg.openjdk.java.net/jdk/jdk/rev/e9db10a375d9 User: eosterlund Date: 2019-05-14 11:51:27 +0000
14-05-2019