Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-08-14 Thread Axel Boldt-Christmas
On Tue, 13 Aug 2024 16:03:16 GMT, Roman Kennke wrote: >> I tried the following (see diff below) and it shows about a 5-10% regression >> in most the `LockUnlock.testInflated*` micros. Also tried with just >> `num_unrolled = 1` saw the same regression. Maybe there was some other >> pattern you

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-08-13 Thread Roman Kennke
On Tue, 13 Aug 2024 12:57:23 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 674: >> >>> 672: >>> 673: // Search for obj in cache. >>> 674: bind(loop); >> >> Same loop transformation would be possible here. > > I tried the following (see diff

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-08-13 Thread Coleen Phillimore
On Mon, 12 Aug 2024 14:37:50 GMT, Axel Boldt-Christmas wrote: >> This is a really good suggestion and might help a lot with the performance >> problems that we see with the table with heavily contended locking. I think >> we should change this in a follow-on patch (which I'll work on). > > I

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-08-13 Thread Axel Boldt-Christmas
On Tue, 23 Jul 2024 14:27:34 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 105: >> >>> 103: }; >>> 104: >>> 105: class LookupMonitor : public StackObj { >> >> I'm not understanding why we need this little wrapper class. > > It's a two way looku

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-08-13 Thread Axel Boldt-Christmas
On Tue, 23 Jul 2024 16:36:18 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 102: >> >>> 100: assert(*value != nullptr, "must be"); >>> 101: return (*value)->object_is_cleared(); >>> 102: } >> >> The `is_dead` functions seem oddly plac

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-08-13 Thread Axel Boldt-Christmas
On Tue, 23 Jul 2024 13:19:02 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 62: >> >>> 60: class ObjectMonitorWorld : public CHeapObj { >>> 61: struct Config { >>> 62: using Value = ObjectMonitor*; >> >> Does this alias really help? We don't st

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-08-13 Thread Axel Boldt-Christmas
On Tue, 23 Jul 2024 20:21:05 GMT, Coleen Phillimore wrote: >> Only legacy locking uses the displaced header, I believe, which isn't clear >> in this code at all. This seems like a fix. We should probably assert that >> only legacy locking uses this field as a displaced header. > > Update: yes

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-08-13 Thread Axel Boldt-Christmas
On Tue, 16 Jul 2024 12:36:08 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 >> additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-08-12 Thread Axel Boldt-Christmas
On Tue, 23 Jul 2024 13:20:27 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 77: >> >>> 75: using ConcurrentTable = ConcurrentHashTable>> MEMFLAGS::mtObjectMonitor>; >>> 76: >>> 77: ConcurrentTable* _table; >> >> So you have a class ObjectMonitor

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-08-12 Thread Axel Boldt-Christmas
On Wed, 17 Jul 2024 06:48:03 GMT, David Holmes wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 >> additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-23 Thread Coleen Phillimore
On Tue, 23 Jul 2024 13:12:23 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/deoptimization.cpp line 1641: >> >>> 1639: assert(fr.is_deoptimized_frame(), "frame must be >>> scheduled for deoptimization"); >>> 1640: if (LockingMode == LM_LEGACY) { >>> 1641:

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-23 Thread Coleen Phillimore
On Thu, 18 Jul 2024 11:30:27 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 >> additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-23 Thread Coleen Phillimore
On Wed, 17 Jul 2024 06:40:31 GMT, David Holmes wrote: >> src/hotspot/share/runtime/basicLock.hpp line 46: >> >>> 44: // Used as a cache the ObjectMonitor* used when locking. Must either >>> 45: // be nullptr or the ObjectMonitor* used when locking. >>> 46: volatile uintptr_t _metadata; >>

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-23 Thread Coleen Phillimore
On Wed, 17 Jul 2024 06:35:34 GMT, David Holmes wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 >> additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-23 Thread Coleen Phillimore
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-19 Thread Andrey Turbanov
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-18 Thread Roman Kennke
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-17 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Wed, 17 Jul 2024 06:39:14 GMT, David Holmes wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 >> additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread David Holmes
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread Roman Kennke
On Tue, 16 Jul 2024 12:37:43 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with 10 >> additional commits since the last revision: >> >> - Remove try_read >> - Add explicit to single parameter constructors >> - Remove superfluous access specifier

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-16 Thread Roman Kennke
On Mon, 15 Jul 2024 00:50:30 GMT, Axel Boldt-Christmas wrote: >> When inflating a monitor the `ObjectMonitor*` is written directly over the >> `markWord` and any overwritten data is displaced into a displaced >> `markWord`. This is problematic for concurrent GCs which needs extra care or >> l

Re: RFR: 8315884: New Object to ObjectMonitor mapping [v9]

2024-07-14 Thread Axel Boldt-Christmas
> When inflating a monitor the `ObjectMonitor*` is written directly over the > `markWord` and any overwritten data is displaced into a displaced `markWord`. > This is problematic for concurrent GCs which needs extra care or looser > semantics to use this displaced data. In Lilliput this data als