[master] RFR: 8302209: [Lilliput] Optimize fix-anon monitor owner path [v2]

[Roman Kennke]

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Wed, 8 Mar 2023 07:04:09 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Stupid question, is it guaranteed that the branch op always works with the location the stub is emitted to? Is there a mechanism to check that its is not too far away? Or is the code heap always small enough for every branch instruction used?

There are asserts in the branch instructions that check that the branch can be encoded. The stubs get emitted right after the method code. Not sure if there is any reasonable way that this could be too far away, but this is the way it is done since forever in C1 and recently also in C2. I would not be too worried about it.
 
> Reading through this and through the justification for biased-locking removal, it seems that which of those two scenarios are more common today is not so clear cut, right? So modern applications see more contented locking and less locking altogether than old apps?

The scenario in which fast-locking (or stack-locking or biased-locking) really helps is actually pretty narrow. Code would have to:
- do uncontended locking
AND
- using different lock objects

Because if it would be using the same lock-object over and over, the cost of allocating ('inflating') a true ObjectMonitor would be quickly amortised. The locking/unlocking primitives with OM should be as fast as with stack-/fast-locking (basically a single CAS plus some small stuff). Only in single-use (or relatively few used) uncontented locks is where fast-/stack-(/biased-)locking would gain anything compared to pure ObjectMonitor locking. Unfortunately, this still happens in a few scenarios: StringBuffer is one such place that is basically guaranteed to be single-threaded, and they're also very often throwaway objects. Collections and I/O streams I would expect to be reused often/long enough to amortise the OM inflation, but some code uses them in a throwaway fashion, too. And then there are cases where synchronized is used in outright stupid nonsense ways.

-------------

PR: https://git.openjdk.org/lilliput/pull/74