JDK-8232391 : consolidate various kinds of HotSpot return barriers
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 14
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2019-10-16
  • Updated: 2024-07-10
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8214584 - stackwalk returns null for scalar-replaced value
Description
A return barrier is a patched return PC word that vectors to some kind of fixup code and then eventually returns to the actual caller (the un-patched return PC word).  There are several variations on this theme in HotSpot, and more seem to be in our future.  For better maintainability and robustness, there should be just one (or as few as possible) such mechanisms.

A patched return PC can only be patched to one value.  This means that if there are two extra events in modules A, B that need to happen on return, then we need to avoid a situation where A is patched and then B overwrites the patch of A, causing the event for A to be lost.  We avoid this by having A know about B, and/or B know about A.  So if B "sees" A's return PC patch, B takes on the burden of executing A's fixup logic.  This pattern can be continued for B, C, D, etc., but the couplings between the modules are excessive.

Also, a stack walker may need to recognize all possible return patches.  This adds more cross-module couplings.  It's probably harder to maintain and more prone to bugs than a single integrated mechanism X which handles all requests for A, B, etc.

This enhancement calls for such a mechanism X.

Possible current uses of X:
 - deoptimize caller on return
 - execute JVMTI action on return

Possible future uses of X:
 - thaw Loom continuation frame on return
 - free frame-local resources on return (Loom? tail-call argument storage?)
 - remove doPrivileged protection domain marker?
 - release frame-local resource reservation (spare heap for OOM processing)?
 - perform some other VM-managed cleanup
 - emit JFR event or increment external performance counter (after dynamic registration of interest)
 - concurrent thread stack scanning (ZGC)
Comments
Off the top of my head, I can think of the following types of return barriers currently used by HotSpot: 1. Thread handshake 2. Loom call-site patched nop 3. ReservedStackAccess unguard check 4. return address patching As far as I known, none of these are used for inlined frames. The closest thing we have for that is the monitexit logic that gets executed when exiting an inlined synchronized method. I was thinking return barriers could be used to clean-up frame-specific metadata (ScopedValue bindings, for example) after an asynchronous OutOfMemory or StackOverflow error, but it would need to work for inlined frames. Generalizing the ReservedStackAccess unguard check into a generic ReturnBarrier check and emitting it for inlined return could potentially help here. The hook that gets called would need to examine the scope information for the PC to determine the target inlined frame, because the SP will be the same for all of them. However, for this particular use case, if we deoptimized the compiled frame then we no longer need a return barrier at inlined return boundaries.
08-11-2022