On Sat, 26 Oct 2024 02:15:29 GMT, Dean Long <dl...@openjdk.org> wrote:
> > On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual
> > thread will call freeze to copy all Java frames to the heap. We will add
> > the virtual thread to the ObjectMonitor's queue and return back to Java.
> > Instead of continue execution in Java though, the virtual thread will jump
> > to a preempt stub which will clear the frames copied from the physical
> > stack, and will return to `Continuation.run()` to proceed with the unmount
> > logic.
>
> During this time, the Java frames are not changing, so it seems like it
> doesn't matter if the freeze/copy happens immediately or after we unwind the
> native frames and enter the preempt stub. In fact, it seems like it could be
> more efficient to delay the freeze/copy, given the fact that the preemption
> can be canceled.
>
The problem is that freezing the frames can fail. By then we would have already
added the ObjectWaiter as representing a virtual thread. Regarding efficiency
(and ignoring the previous issue) both approaches would be equal anyways, since
regardless of when you freeze, while doing the freezing the monitor could have
been released already. So trying to acquire the monitor after freezing can
always succeed, which means we don't want to unmount but continue execution,
i.e cancel the preemption.
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 133:
>
>> 131:
>> 132: inline void FreezeBase::prepare_freeze_interpreted_top_frame(const
>> frame& f) {
>> 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0,
>> "should be null for top frame");
>
> Suggestion:
>
> assert(f.interpreter_frame_last_sp() == nullptr, "should be null for top
> frame");
Changed, here and in the other platforms.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442387426
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819592799
