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