On Wed, 12 Feb 2025 16:28:32 GMT, Vladimir Kozlov wrote:
>> Remove virtual methods from CodeBlob and nmethod to simplify
>> saving/restoring in Leyden AOT cache. It avoids the need to patch hidden
>> VPTR pointer to class's virtual table.
>>
>> Added C++ static asserts to make sure no virtual
On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Tue, 22 Oct 2024 19:04:16 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234:
>>
>>> 2232: retry_fast_path = true;
>>> 2233: } else {
>>> 2234: relativize_chunk_concurrently(chunk);
>>
>> Is the `relativize_chunk_concurrently` solu
On Wed, 23 Oct 2024 00:08:54 GMT, Coleen Phillimore wrote:
>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341:
>>
>>> 5339:
>>> 5340: void MacroAssembler::inc_held_monitor_count() {
>>> 5341: Address dst = Address(rthread,
>>> JavaThread::held_monitor_count_offset());
>>
>> Sug
On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo
wrote:
> This is the implementation of JEP 491: Synchronize Virtual Threads without
> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
> further details.
>
> In order to make the code review easier the changes hav
On Wed, 6 Nov 2024 00:08:16 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes
On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes
On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the changes
On Thu, 31 Oct 2024 21:50:50 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Fri, 25 Oct 2024 08:25:21 GMT, Axel Boldt-Christmas
wrote:
>> This is the implementation task for `JEP 490: ZGC: Remove the
>> Non-Generational Mode`. See the JEP for details.
>> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
>
> Axel Boldt-Christ
On Tue, 8 Oct 2024 07:20:49 GMT, Axel Boldt-Christmas
wrote:
> This is the implementation task for `JEP 490: ZGC: Remove the
> Non-Generational Mode`. See the JEP for details.
> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
This pull request has now been integrated.
> This is the implementation task for `JEP 490: ZGC: Remove the
> Non-Generational Mode`. See the JEP for details.
> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
Axel Boldt-Christmas has updated the pull request with a new target base due to
a merge or a rebase. The pul
On Wed, 23 Oct 2024 00:08:54 GMT, Coleen Phillimore wrote:
>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341:
>>
>>> 5339:
>>> 5340: void MacroAssembler::inc_held_monitor_count() {
>>> 5341: Address dst = Address(rthread,
>>> JavaThread::held_monitor_count_offset());
>>
>> Sug
On Tue, 22 Oct 2024 19:04:16 GMT, Patricio Chilano Mateo
wrote:
>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234:
>>
>>> 2232: retry_fast_path = true;
>>> 2233: } else {
>>> 2234: relativize_chunk_concurrently(chunk);
>>
>> Is the `relativize_chunk_concurrently` solu
On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Mon, 21 Oct 2024 15:45:21 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
> This is the implementation task for `JEP 490: ZGC: Remove the
> Non-Generational Mode`. See the JEP for details.
> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
Axel Boldt-Christmas has updated the pull request with a new target base due to
a merge or a rebase. The pul
> This is the implementation task for `JEP 490: ZGC: Remove the
> Non-Generational Mode`. See the JEP for details.
> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
Axel Boldt-Christmas has updated the pull request with a new target base due to
a merge or a rebase. The in
On Thu, 10 Oct 2024 11:59:24 GMT, Axel Boldt-Christmas
wrote:
>> This is a regression from
>> [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
>>
>> When using `+UseObjectMonitorTable` monitors are inflated in a locked state
>> effe
On Wed, 9 Oct 2024 11:16:46 GMT, Axel Boldt-Christmas
wrote:
> This is a regression from
> [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
>
> When using `+UseObjectMonitorTable` monitors are inflated in a locked state
> effectively blockin
On Wed, 9 Oct 2024 11:16:46 GMT, Axel Boldt-Christmas
wrote:
> This is a regression from
> [JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
>
> When using `+UseObjectMonitorTable` monitors are inflated in a locked state
> effectively blockin
using
> `LightweightSynchronizer::enter_for` is that the object being synchronized
> can not have been reached by another JavaThread (except the deflating
> thread). So there may never be contention, but there may be deflation.
Axel Boldt-Christmas has updated the pull request incremen
> This is the implementation task for `JEP 490: ZGC: Remove the
> Non-Generational Mode`. See the JEP for details.
> [JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
Axel Boldt-Christmas has updated the pull request incrementally with six
additional commits since the last
This is the implementation task for `JEP 490: ZGC: Remove the Non-Generational
Mode`. See the JEP for details.
[JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850)
-
Commit messages:
- Remove XCollectedHeap from HSDB
- Fix typo in TestZUncommitEvent.java
- Add missing probl
This is a regression from
[JDK-8315884](https://bugs.openjdk.org/browse/JDK-8315884).
When using `+UseObjectMonitorTable` monitors are inflated in a locked state
effectively blocking out deflation. `LightweightSynchronizer::enter_for`
assumed this to be true. But when the `-UseObjectMonitorTabl
On Mon, 30 Sep 2024 07:39:11 GMT, Axel Boldt-Christmas
wrote:
> [JDK-8322630](https://bugs.openjdk.org/browse/JDK-8322630) / #17495 removed
> the the concept of ICStubs, InlineCache buffers and related safepoints.
>
> There are a handfull of references and auxiliary constructs
On Mon, 30 Sep 2024 08:15:51 GMT, Axel Boldt-Christmas
wrote:
>> [JDK-8322630](https://bugs.openjdk.org/browse/JDK-8322630) / #17495 removed
>> the the concept of ICStubs, InlineCache buffers and related safepoints.
>>
>> There are a handfull of references and auxil
is removes the unused:
> * Experimental `InlineCacheBufferSize` option
> * `InlineCacheBuffer_lock` mutex
> * `Thread::_missed_ic_stub_refill_verifier` field
> * `VM_ICBufferFull` VM operation
Axel Boldt-Christmas has updated the pull request incrementally with one
additional commi
[JDK-8322630](https://bugs.openjdk.org/browse/JDK-8322630) / #17495 removed the
the concept of ICStubs, InlineCache buffers and related safepoints.
There are a handfull of references and auxiliary constructs still in the code,
I propose we clean these out.
This removes the unused:
* Experiment
On Mon, 16 Sep 2024 13:28:00 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> prev
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
On Thu, 15 Aug 2024 06:12:22 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 n
On Thu, 15 Aug 2024 13:45:11 GMT, Yudi Zheng wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove newline
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 677:
>
On Fri, 12 Jul 2024 10:12:32 GMT, Roman Kennke wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update arguments.cpp
>
> Is there a plan to get rid of the UseObjectMonitorTab
On Wed, 14 Aug 2024 21:02:47 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use jdk.test.lib.Utils.getRandomInstance()
>
> src/hotspot/share/run
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
On Wed, 14 Aug 2024 20:58:24 GMT, Daniel D. Daugherty
wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 341:
>>
>>> 339:
>>> 340: ObjectMonitor*
>>> LightweightSynchronizer::get_or_insert_monitor_from_table(oop object,
>>> JavaThread* current, bool* inserted) {
>>> 341:
On Tue, 13 Aug 2024 21:56:29 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Whitespace and nits
>
> src/hotspot/share/runtime/vframe.cpp lin
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
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
On Wed, 14 Aug 2024 05:45:27 GMT, David Holmes wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Whitespace and nits
>
> src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp l
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
On Tue, 13 Aug 2024 21:45:57 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Whitespace and nits
>
> src/hotspot/share/runtime/synchron
On Tue, 13 Aug 2024 21:05:29 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_wor
On Tue, 13 Aug 2024 18:13:30 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_wor
On Tue, 13 Aug 2024 17:05:38 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_wor
On Tue, 13 Aug 2024 16:34:17 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Remove the last OMWorld references
>> - Rename omworldtable_wor
On Mon, 12 Aug 2024 22:40:06 GMT, Daniel D. Daugherty
wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Missing DEBUG_ONLY
>
> src/hotspot/share/interpreter/zero/bytecodeInter
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
On Mon, 12 Aug 2024 18:55:41 GMT, Coleen Phillimore wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Missing DEBUG_ONLY
>
> src/hotspot/share/runtime/lightweightSynchr
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
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
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
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
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
On Fri, 12 Jul 2024 15:32: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/share/runtime/lightweightSynchronizer
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
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
>> -
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
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
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
>> -
On Tue, 23 Jul 2024 16:44:06 GMT, Coleen Phillimore wrote:
>> I wanted to avoid having to add `NoSafepointVerifier` implementation details
>> in the synchroniser code. I guess `ContinuationWrapper` already does this.
>>
>> Simply creating a `NoSafepointVerifier` when you expect no safepoint is
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
On Mon, 15 Jul 2024 00:45:25 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 477:
>>
>>> 475: if (obj->mark_acquire().has_monitor()) {
>>> 476: if (_length > 0 && _contended_oops[_length-
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:
>
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
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));
>>
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
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 unaffec
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.cp
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
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
>> -
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
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 op
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
owing section as a comment in
> the source code
>
> ## Fast Locking
>
> CAS on locking bits in markWord.
> 0b00 (Fast Locked) <--> 0b01 (Unlocked)
>
> When locking and 0b00 (Fast Locked) is observed, it may be beneficial to
> avoid inflating by spinning
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 i
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
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 contai
On Thu, 27 Jun 2024 14:30:43 GMT, Axel Boldt-Christmas
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [5909d541](https://github.com/openjdk/jdk/commit/5909d54147355dd7da5786ff39ead4c15816705c)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repos
On Thu, 27 Jun 2024 14:30:43 GMT, Axel Boldt-Christmas
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [5909d541](https://github.com/openjdk/jdk/commit/5909d54147355dd7da5786ff39ead4c15816705c)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repos
Hi all,
This pull request contains a backport of commit
[5909d541](https://github.com/openjdk/jdk/commit/5909d54147355dd7da5786ff39ead4c15816705c)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Axel Boldt-Christmas on 27 Jun 2024
On Tue, 18 Jun 2024 12:25:36 GMT, Axel Boldt-Christmas
wrote:
> ClassLoaderDataGraph provides APIs for walking different metadata. All the
> iterators which are not designed to be used by the GC also keep the holder of
> the CLDs alive and by extensions keeps all metadata alive
On Thu, 27 Jun 2024 13:38:22 GMT, Axel Boldt-Christmas
wrote:
>> ClassLoaderDataGraph provides APIs for walking different metadata. All the
>> iterators which are not designed to be used by the GC also keep the holder
>> of the CLDs alive and by extensions keeps all metad
JDK-8326005) consistently
> within a few hours. And after this patch it does not.
>
> Currently running tier1-tier8 testing.
Axel Boldt-Christmas has updated the pull request incrementally with one
additional commit since the last revision:
Cleanup soon
-
Chang
JDK-8326005) consistently
> within a few hours. And after this patch it does not.
>
> Currently running tier1-tier8 testing.
Axel Boldt-Christmas has updated the pull request incrementally with five
additional commits since the last revision:
- Rename iterator
- Add SystemDicti
JDK-8326005) consistently
> within a few hours. And after this patch it does not.
>
> Currently running tier1-tier8 testing.
Axel Boldt-Christmas has updated the pull request incrementally with one
additional commit since the last revision:
Rename and comment SystemDictionary::metho
On Wed, 19 Jun 2024 08:53:33 GMT, Stefan Karlsson wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Document the iterator and functions
>
> src/hotspot/share/classfile/
JDK-8326005) consistently
> within a few hours. And after this patch it does not.
>
> Currently running tier1-tier8 testing.
Axel Boldt-Christmas has updated the pull request incrementally with one
additional commit since the last revision:
Document the iterator and functions
-
On Tue, 18 Jun 2024 13:33:55 GMT, Erik Österlund wrote:
>> ClassLoaderDataGraph provides APIs for walking different metadata. All the
>> iterators which are not designed to be used by the GC also keep the holder
>> of the CLDs alive and by extensions keeps all metadata alive. This is
>> proble
On Tue, 18 Jun 2024 13:41:05 GMT, Erik Österlund wrote:
>> src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp line 108:
>>
>>> 106: // and collect them using the LoadedClassesClosure
>>> 107: MutexLocker mcld(ClassLoaderDataGraph_lock);
>>> 108: ClassLoaderDataGraph::loaded_classes_do
On Tue, 18 Jun 2024 13:42:24 GMT, Erik Österlund wrote:
>> ClassLoaderDataGraph provides APIs for walking different metadata. All the
>> iterators which are not designed to be used by the GC also keep the holder
>> of the CLDs alive and by extensions keeps all metadata alive. This is
>> proble
ClassLoaderDataGraph provides APIs for walking different metadata. All the
iterators which are not designed to be used by the GC also keep the holder of
the CLDs alive and by extensions keeps all metadata alive. This is problematic
for concurrent GC as it keeps otherwise unreachable classes from
On Thu, 4 Apr 2024 00:05:20 GMT, Vladimir Kozlov wrote:
>> Revert [JDK-8152664](https://bugs.openjdk.org/browse/JDK-8152664) RFE
>> [changes](https://github.com/openjdk/jdk/commit/b853eb7f5ca24eeeda18acbb14287f706499c365)
>> which was used for AOT [JEP 295](https://openjdk.org/jeps/295)
>> imp
1 - 100 of 156 matches
Mail list logo
