JDK-8324881 : ObjectSynchronizer::inflate(Thread* current...) is invoked for non-current thread
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 21.0.2,22,23,repo-lilliput-17
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-01-30
  • Updated: 2024-03-25
  • Resolved: 2024-02-07
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 23
23 b09Fixed
Related Reports
Relates :  
JDK-8227745 - Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Relates :  
JDK-8318895 - Deoptimization results in incorrect lightweight locking stack
Description
The method 
'
ObjectMonitor* ObjectSynchronizer::inflate(Thread* current, oop object, const InflateCause cause)
'
expect to be invoked with the current thread.
However in the method
 Deoptimization::relock_objects()
it is executed with deoptee thread.

See:
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/deoptimization.cpp#L1650
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/lilliput-jdk21u/pull/22 Date: 2024-03-25 16:22:24 +0000
25-03-2024
Changeset: a3a2b1fb Author: Axel Boldt-Christmas <aboldtch@openjdk.org> Date: 2024-02-07 15:49:16 +0000 URL: https://git.openjdk.org/jdk/commit/a3a2b1fbbf00577ce1d0e3a44e9537e997b30b05
07-02-2024
This broken behaviour was introduced by JDK-8227745, which allowed EA to be used with JVMTI.
31-01-2024
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/17626 Date: 2024-01-30 10:03:41 +0000
30-01-2024
There is definitely a significant issue here. The deopt code was added by JDK-8318895 for lightweight locking. It is not immediately obvious that the passed in thread needs to be the current thread in terms of locking, but there are uses of it with ResourceMark that do require it to be the current thread. EDIT: yes it does need to be the current thread for a range of reasons. The whole operation of the methods varies depending on whether the owner is the current thread or not.
30-01-2024
Sorry, the correct question should rather "why there is a requirement to thread to be current except using in logging" the ResourceMark might be easily updated if it is enough to have the thread in a safe state.
30-01-2024
Not sure why there is a requirement to thread to be current, would be nice to add comments.
30-01-2024
Also, method void ObjectSynchronizer::enter(Handle obj, BasicLock* lock, JavaThread* current) {..} is invoked with non-current thread here: https://github.com/openjdk/jdk/blame/master/src/hotspot/share/runtime/deoptimization.cpp#L1654
30-01-2024