RFR: 8291555: Implement alternative fast-locking scheme [v27]
Robbin Ehn
rehn at openjdk.org
Thu Mar 16 08:15:38 UTC 2023
On Thu, 16 Mar 2023 08:00:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> I like UseNewLocks but fear that this may conflict with Oracles plan (?) to move OMs into heap, which would be another revamp of locking - fat locks in this case - and may come with yet another switch. Other than that, UseNewLocks sounds good and succinct.
>
> Another proposal: UseThreadLockStack or UseLockStack
Just a FYI, at the moment we have:
product(ccstr, ObjectSynchronizerMode, "fast", \
"ObjectSynchronizer modes: " \
"legacy: legacy native system; " \
"native: java entry with native monitors; " \
"heavy: java entry with always inflated Java monitors; " \
"fast: java entry with fast-locks and" \
" inflate-on-demand Java monitors; ") \
At least personally I prefer one option than using many.
A cmd line with e.g.
`-XX:-UseLockStack -XX:+UseHeavyMonitors`
It's harder, for me ?, to figure out what is selected and what was intended to be selected.
-------------
PR: https://git.openjdk.org/jdk/pull/10907
More information about the serviceability-dev
mailing list