JDK-8273143 : Transition to _thread_in_vm when handling a polling page exception
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-08-30
  • Updated: 2022-01-25
  • Resolved: 2022-01-13
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 19
19 b06Fixed
Related Reports
Relates :  
Description
We should make a transition to _thread_in_vm when processing a polling page exception since we are already executing in the vm. This will also allow us to avoid having to consider yet another state(_thread_in_Java) when calling SafepointMechanism::process_if_requested_with_exit_check() which otherwise forces called code to be aware of thread state and possibly make transitions to _thread_in_vm and back.
Comments
Changeset: 237f861e Author: Patricio Chilano Mateo <pchilanomate@openjdk.org> Date: 2022-01-13 17:49:01 +0000 URL: https://git.openjdk.java.net/jdk/commit/237f861e8245749cb260fa81e7797d337dc15e22
13-01-2022

A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk/pull/7009 Date: 2022-01-10 14:08:17 +0000
10-01-2022

Once we are in ThreadSafepointState::handle_polling_page_exception() we are in a slow path, so setting the thread state will not change anything in terms of performance. Plus the idea is to get rid of ThreadInVMForHandshake eventually so if the pending operation was actually a handshake we are just moving the place where we transition from Java to vm and from vm back to Java.
31-08-2021

Won't this incur some overhead?
31-08-2021