RFR: 8291555: Implement alternative fast-locking scheme [v27]
Thomas Stuefe
stuefe at openjdk.org
Thu Mar 16 10:29:31 UTC 2023
On Thu, 16 Mar 2023 10:20:21 GMT, Robbin Ehn <rehn at openjdk.org> wrote:
>
> > > > @rkennke I must be missing something. In aarch64, why do we handle the non-symmetric-unlock case in interpreter, but not in C1/C2? There, we just seem to pop whatever is on top.
> > >
> > >
> > > C1 and C2 don't allow assymmetric locking. If that ever happens, they would refuse to compile the method. We should probably check that this assumption holds true when popping the top entry in an #ASSERT block.
> >
> >
> > Thanks for clarifying. Yes, asserting that would make sense.
>
> FYI: I'm trying to convince folks that JVMS should be allowed to enforce asymmetric locking. We think most people don't know they will be stuck in interpreter, unintended. What was discussed latest was to diagnose and warn about this behavior as a first step.
Sounds good. Just to be clear, you mean enforce symmetric locking? resp. forbid asymmetric locking?
-------------
PR: https://git.openjdk.org/jdk/pull/10907
More information about the serviceability-dev
mailing list