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) { >>>

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 [v6]

2024-07-23 Thread Coleen Phillimore
On Mon, 15 Jul 2024 00:44:31 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/basicLock.cpp line 37: >> >>> 35: if (mon != nullptr) { >>> 36: mon->print_on(st); >>> 37: } >> >> I am not sure if we wanted to do this, but we know the owner, therefore we >> could also

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

2024-07-23 Thread Coleen Phillimore
On Tue, 23 Jul 2024 12:34:45 GMT, Coleen Phillimore wrote: >> I was thinking it was referring to `ObjectSynchronizer::waitUninterruptibly` >> added the same commit as the comment b3bf31a0a08da679ec2fd21613243fb17b1135a9 > > git backout restored the old wrong comment. We should fix this

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 >>

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

2024-07-23 Thread Coleen Phillimore
On Mon, 15 Jul 2024 00:44:02 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/oops/instanceKlass.cpp line 1090: >> >>> 1088: >>> 1089: // Step 2 >>> 1090: // If we were to use wait() instead of waitUninterruptibly() then >> >> This is a nice correction (even though, the actual

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 >>

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 >>

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 >>

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 >>

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 >>

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

2024-07-17 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-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 >>

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 >>

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 >>

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

2024-07-14 Thread Axel Boldt-Christmas
On Fri, 12 Jul 2024 11:09:35 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/share/oops/instanceKlass.cpp line 1090: > >> 1088: >> 1089: // Step

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

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

2024-07-12 Thread Coleen Phillimore
On Fri, 12 Jul 2024 15:58:56 GMT, Roman Kennke wrote: >> src/hotspot/share/runtime/synchronizer.cpp line 390: >> >>> 388: >>> 389: static bool useHeavyMonitors() { >>> 390: #if defined(X86) || defined(AARCH64) || defined(PPC64) || >>> defined(RISCV64) || defined(S390) >> >> Why are those

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

2024-07-12 Thread Roman Kennke
On Tue, 9 Jul 2024 20:43:06 GMT, Coleen Phillimore wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Add JVMCI symbol exports >> - Revert "More graceful JVMCI VM option interaction" >> >>This

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

2024-07-12 Thread Roman Kennke
On Fri, 12 Jul 2024 15:56:59 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/share/runtime/synchronizer.cpp line 390: > >> 388: >> 389: static bool

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

2024-07-12 Thread Roman Kennke
On Fri, 12 Jul 2024 05:57: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 >>

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

2024-07-12 Thread Axel Boldt-Christmas
On Fri, 12 Jul 2024 12:06:05 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343: >> >>> 341: const Register t3_owner = t3; >>> 342: const ByteSize monitor_tag = in_ByteSize(UseObjectMonitorTable ? 0 >>> : checked_cast(markWord::monitor_value));

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

2024-07-12 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

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

2024-07-12 Thread Coleen Phillimore
On Fri, 12 Jul 2024 10:54:23 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 >>

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

2024-07-12 Thread Andrew Haley
On Fri, 12 Jul 2024 09:40:45 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 343: > >> 341: const

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

2024-07-12 Thread Axel Boldt-Christmas
On Fri, 12 Jul 2024 09:53:11 GMT, Roman Kennke wrote: > When you say 'This patch has been evaluated to be performance neutral when > UseObjectMonitorTable is turned off (the default).' - what does the > performance look like with +UOMT? How does it compare to -UOMT? Most benchmarks are

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

2024-07-12 Thread Axel Boldt-Christmas
On Fri, 12 Jul 2024 09:32:44 GMT, Roman Kennke wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Update arguments.cpp > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 318: > >> 316: >> 317:

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

2024-07-12 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

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

2024-07-12 Thread Roman Kennke
On Fri, 12 Jul 2024 05:57: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 >>

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

2024-07-12 Thread Roman Kennke
On Fri, 12 Jul 2024 05:57: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 >>

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

2024-07-11 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

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

2024-07-11 Thread Coleen Phillimore
On Wed, 10 Jul 2024 09:41:37 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 763: >> >>> 761: assert(mark.has_monitor(), "must be"); >>> 762: // The monitor exists >>> 763: ObjectMonitor* monitor = ObjectSynchronizer::read_monitor(current,

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

2024-07-11 Thread Coleen Phillimore
On Wed, 10 Jul 2024 09:41:08 GMT, Axel Boldt-Christmas wrote: >> src/hotspot/share/runtime/arguments.cpp line 1830: >> >>> 1828: FLAG_SET_CMDLINE(LockingMode, LM_LIGHTWEIGHT); >>> 1829: warning("UseObjectMonitorTable requires LM_LIGHTWEIGHT"); >>> 1830: } >> >> Maybe we want this to

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

2024-07-11 Thread Axel Boldt-Christmas
On Thu, 11 Jul 2024 09:25:52 GMT, Yudi Zheng wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with four >> additional commits since the last revision: >> >> - Add extra comments in LightweightSynchronizer::inflate_fast_locked_object >> - Fix typos >> - Remove unused

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

2024-07-11 Thread Yudi Zheng
On Wed, 10 Jul 2024 20:10:07 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 >>

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

2024-07-10 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

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

2024-07-10 Thread Axel Boldt-Christmas
On Tue, 9 Jul 2024 20:44:58 GMT, Coleen Phillimore wrote: >> Axel Boldt-Christmas has updated the pull request incrementally with two >> additional commits since the last revision: >> >> - Add JVMCI symbol exports >> - Revert "More graceful JVMCI VM option interaction" >> >>This

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

2024-07-10 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

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

2024-07-09 Thread Coleen Phillimore
On Mon, 8 Jul 2024 16:21:16 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 >>

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

2024-07-08 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

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

2024-07-08 Thread Yudi Zheng
On Mon, 8 Jul 2024 12:13:07 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 >>

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

2024-07-08 Thread Thomas Wuerthinger
On Mon, 8 Jul 2024 12:13:07 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 >>

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

2024-07-08 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

Re: RFR: 8315884: New Object to ObjectMonitor mapping

2024-07-08 Thread Axel Boldt-Christmas
On Mon, 8 Jul 2024 10:58:29 GMT, Thomas Wuerthinger wrote: > OK. Will there be a CSR or JEP for this? There is no plan for this, nor should it be required. It’s an internal implementation. > When do you approximately expect this to land in main line? ASAP. Compatibility for the field name

Re: RFR: 8315884: New Object to ObjectMonitor mapping

2024-07-08 Thread Thomas Wuerthinger
On Mon, 8 Jul 2024 08:18:42 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 looser

Re: RFR: 8315884: New Object to ObjectMonitor mapping

2024-07-08 Thread Axel Boldt-Christmas
On Mon, 8 Jul 2024 09:39:32 GMT, Thomas Wuerthinger wrote: > Is this change expected to require JVMCI and/or Graal JIT changes? Support for `UseObjectMonitorTable` would require changes to Graal JIT. (`UseObjectMonitorTable` is off by default). Minimal support would be to call into the VM for

Re: RFR: 8315884: New Object to ObjectMonitor mapping

2024-07-08 Thread Thomas Wuerthinger
On Mon, 8 Jul 2024 08:18:42 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 looser

RFR: 8315884: New Object to ObjectMonitor mapping

2024-07-08 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 also