JDK-8276824 : refactor Thread::is_JavaThread_protected
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2021-11-08
  • Updated: 2021-11-15
  • Resolved: 2021-11-12
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 18
18 masterFixed
Related Reports
Relates :  
JDK-8249004 - Reduce ThreadsListHandle overhead in relation to direct handshakes
Description
During the code review for the following RFE:

    JDK-8249004 Reduce ThreadsListHandle overhead in relation to direct handshakes

[~coleenp] mentioned that she was not happy about the
"bool checkTLHOnly" parameter that was added to
Thread::is_JavaThread_protected(). The new parameter
basically turned Thread::is_JavaThread_protected() into
two different functions with the decision on which one to
execute based on the new parameter. She would prefer
to refactor Thread::is_JavaThread_protected() into two
functions and have Thread::is_JavaThread_protected()
call the new function for the portion of the logic that was
moved.

The new calls to Thread::is_JavaThread_protected() that
passed "true" for the second parameter would change to
call the new function.
Comments
Changeset: 176d21d6 Author: Daniel D. Daugherty <dcubed@openjdk.org> Date: 2021-11-12 19:06:01 +0000 URL: https://git.openjdk.java.net/jdk/commit/176d21d6c525f8fd9592db5b4975308ea0001856
12-11-2021