On Mon, 9 Jan 2023 10:30:06 GMT, Fredrik Bredberg wrote:
> Implementation of relativized locals in interpreter frames for x86. x64, arm,
> aarch64, ppc64le and riscv.
> Not relativized locals on zero and s390 but done some changes to cope with
> the changed generic code.
> Tested tier1-tier8 on
On Wed, 3 May 2023 21:58:25 GMT, Stefan Karlsson wrote:
> I'm getting build warnings on all linux platforms with gcc-11.3.0:
>
> ```
> src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library,
> "minor" is defined
> by . For historical compatibility, it is
> currently defined by
On Thu, 4 May 2023 09:50:23 GMT, Axel Boldt-Christmas
wrote:
>>> I'm getting build warnings on all linux platforms with gcc-11.3.0:
>>>
>>> ```
>>> src/hotspot/share/gc/z/zDriver.cpp:84:13: error: In the GNU C Library,
>>> "minor&qu
On Tue, 9 May 2023 12:55:42 GMT, Stefan Karlsson wrote:
>> Hi all,
>>
>> Please review the implementation of Generational ZGC, which can be turned on
>> by adding -XX:+ZGenerational in addition to using -XX:+UseZGC. Generational
>> ZGC is a major rewrite of the non-generational ZGC version tha
The current implementation for testing generational ZGC with jtreg is
implemented with a filter on the mode flag `ZGenerational`. Because of this
only environments which set this flag explicitly will run most of the tests.
So they get missed in Github Actions and for developers running jtreg loc
a different
> max heap size for ZGenerational, but it is not the intent to dispatch the
> test to both G1 and generational ZGC if Generational ZGC is not specified.
>
> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed
> to not filter but instead disp
On Fri, 16 Jun 2023 11:52:51 GMT, Stefan Karlsson wrote:
> Generational ZGC changed the location where the heap object iterator called
> the visit function. It used to be called when the objects were popped and
> then followed, but it was changed so that the function where called
> immediately
a different
> max heap size for ZGenerational, but it is not the intent to dispatch the
> test to both G1 and generational ZGC if Generational ZGC is not specified.
>
> `test/jdk/java/lang/management/MemoryMXBean/MemoryTest.java` was also changed
> to not filter but instead disp
On Sat, 17 Jun 2023 13:24:24 GMT, Alan Bateman wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix wrong ZGenerational flag in VectorRebracket128Test.java
>
> test/jdk/j
On Fri, 16 Jun 2023 20:31:28 GMT, Daniel D. Daugherty
wrote:
> Hmmm... hopefully `vm.gc.ZSingelgen` is really `vm.gc.ZSinglegen`. If so you
> might want to fix the PR description.
What part are you worried about? When would `vm.gc.ZSingelgen` be invalid?
Also what part of the PR requires fix
On Mon, 19 Jun 2023 09:04:17 GMT, Thomas Stuefe wrote:
> How much time do we spend now in GHAs on the additional Zgenerational tests?
> In any case, this makes sense.
This adds around 40 more tests per platform. The runtime of GHA seems to have a
lot of run to run variance. Most new tests are
On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas
wrote:
>> The current implementation for testing generational ZGC with jtreg is
>> implemented with a filter on the mode flag `ZGenerational`. Because of this
>> only environments which set this flag explicitly will run
On Fri, 16 Jun 2023 09:14:10 GMT, Axel Boldt-Christmas
wrote:
> The current implementation for testing generational ZGC with jtreg is
> implemented with a filter on the mode flag `ZGenerational`. Because of this
> only environments which set this flag explicitly will run most of
Hi all,
This pull request contains a backport of commit
[a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Axel Boldt-Christmas on 20 Jun 2023
On Tue, 20 Jun 2023 11:17:40 GMT, Axel Boldt-Christmas
wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [a0595761](https://github.com/openjdk/jdk/commit/a0595761ef35c4eec8cb84326a869b9473cd5bba)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repos
8290074: Remove implicit arguments for RegisterMap constructor
-
Commit messages:
- Fix spurious semicolon
- Change to scoped enum
- 8290074: Remove implicit arguments for RegisterMap constructor
- 8290074: Remove implicit arguments for RegisterMap constructor
- 8290074: Remove i
On Tue, 26 Jul 2022 16:25:04 GMT, Thomas Schatzl wrote:
>> Currently the `RegisterMap` constructor uses implicit boolean arguments to
>> configure its function. Implicit boolean arguments makes code harder to
>> understand and reason about at the call site. Using explicit scoped enums
>> inste
es };
>
>
> Testing: tier1-3
Axel Boldt-Christmas has updated the pull request incrementally with one
additional commit since the last revision:
Rename yes to include
-
Changes:
- all: https://git.openjdk.org/jdk/pull/9455/files
- new: https://git.openjdk.org/jd
On Mon, 11 Jul 2022 14:58:07 GMT, Axel Boldt-Christmas wrote:
> Currently the `RegisterMap` constructor uses implicit boolean arguments to
> configure its function. Implicit boolean arguments makes code harder to
> understand and reason about at the call site. Using explicit sco
The proposal is to encapsulate the nmethod mark for deoptimization logic in one
place and only allow access to the `mark_for_deoptimization` from a closure
object:
```C++
class DeoptimizationMarkerClosure : StackObj {
public:
virtual void marker_do(Deoptimization::MarkFn mark_fn) = 0;
};
This
On Wed, 27 Jul 2022 12:55:04 GMT, Axel Boldt-Christmas wrote:
> The proposal is to encapsulate the nmethod mark for deoptimization logic in
> one place and only allow access to the `mark_for_deoptimization` from a
> closure object:
> ```C++
> class DeoptimizationMarkerClo
gives reasons why not marking for
> deoptimization there is ok.
>
> An effect of this encapsulation is that the deoptimization logic was moved
> from the `CodeCache` class to the `Deoptimization` class and the class
> redefinition logic was moved from the `CodeCache` class to the
On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote:
>> The proposal is to encapsulate the nmethod mark for deoptimization logic in
>> one place and only allow access to the `mark_for_deoptimization` from a
>> closure object:
>> ```C++
>> class Deoptimi
On Mon, 1 Aug 2022 04:58:49 GMT, Axel Boldt-Christmas wrote:
>> The proposal is to encapsulate the nmethod mark for deoptimization logic in
>> one place and only allow access to the `mark_for_deoptimization` from a
>> closure object:
>> ```C++
>> class Deoptimi
ptimisation depend will depend on
>> [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237).
>>
>> Will mark this as a draft for now and create a PR for
>> [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first.
Axel Boldt-Christmas has updated the pull request
On Wed, 10 Aug 2022 15:23:46 GMT, Axel Boldt-Christmas wrote:
>> The proposal is to encapsulate the nmethod mark for deoptimization logic in
>> one place and only allow access to the `mark_for_deoptimization` from a
>> closure object:
>> ```C++
>> class Deoptimi
ptimisation depend will depend on
>> [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237).
>>
>> Will mark this as a draft for now and create a PR for
>> [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first.
Axel Boldt-Christmas has updated the pull reques
ptimisation depend will depend on
>> [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237).
>>
>> Will mark this as a draft for now and create a PR for
>> [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first.
Axel Boldt-Christmas has updated the pull reque
ptimisation depend will depend on
>> [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237).
>>
>> Will mark this as a draft for now and create a PR for
>> [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first.
Axel Boldt-Christmas has updated the pull request
On Thu, 18 Aug 2022 08:18:27 GMT, Axel Boldt-Christmas
wrote:
>> The proposal is to encapsulate the nmethod mark for deoptimization logic in
>> one place and only allow access to the `mark_for_deoptimization` from a
>> closure object:
>> ```C++
>> class Deoptimi
On Thu, 18 Aug 2022 08:57:19 GMT, Dean Long wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Cleanup comment
>
> src/hotspot/share/code/compiledMethod.cpp line 128:
>
>
On Fri, 19 Aug 2022 01:17:14 GMT, Dean Long wrote:
>> I think you have to describe the scenario that does not work, because I am
>> not sure I see it.
>>
>> For ease of writing, let me call the currently embedded status `status` and
>> the currently embedded link `next_link`
>> (`=>` means im
ptimisation depend will depend on
>> [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237).
>>
>> Will mark this as a draft for now and create a PR for
>> [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first.
Axel Boldt-Christmas has updated the pull request i
ptimisation depend will depend on
>> [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237).
>>
>> Will mark this as a draft for now and create a PR for
>> [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first.
Axel Boldt-Christmas has updated the pull r
On Thu, 25 Aug 2022 22:20:43 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4157:
>>
>>> 4155: }
>>> 4156: }
>>> 4157: log_debug(redefine, class, nmethod)("Enqueued all nmethods for
>>> deopt");
>>
>> This seems to do the opposite of encaps
ptimisation depend will depend on
>> [JDK-8291237](https://bugs.openjdk.org/browse/JDK-8291237).
>>
>> Will mark this as a draft for now and create a PR for
>> [JDK-8291718](https://bugs.openjdk.org/browse/JDK-8291718) first.
>
> _Update_
> ---
> Testing after 11
On Mon, 29 Aug 2022 08:35:58 GMT, Axel Boldt-Christmas
wrote:
>> The proposal is to encapsulate the nmethod mark for deoptimization logic in
>> one place and only allow access to the `mark_for_deoptimization` from a
>> closure object:
>> ```C++
>> class Deoptimi
On Sat, 22 Oct 2022 01:38:44 GMT, Kim Barrett wrote:
> Please review this change to GrowableArray to support capacity management.
> Two functions are added to GrowableArray, reserve and shrink_to_fit. Also
> renamed the max_length function to capacity.
>
> Used these new functions in StringDedu
ObjectMonitorIterator fails to return the most resent monitor added. It start
with returning the `nextOM()` ObjectMonitor from the `_head` ObjectMonitor but
fails to ever return the `_head` ObjectMonitor.
The current implementation can also not handle that the `_head` is nullptr (no
monitors in
On Mon, 18 Sep 2023 09:54:18 GMT, Axel Boldt-Christmas
wrote:
> ObjectMonitorIterator fails to return the most resent monitor added. It start
> with returning the `nextOM()` ObjectMonitor from the `_head` ObjectMonitor
> but fails to ever return the `_head` ObjectMonitor.
>
llptr` from the question if ObjectMonitorIterator
> is supported.
>
> Testing:
> * Passes all `serviceability/sa` tests
> * Currently running tier 1-3
> * Currently running GHA
Axel Boldt-Christmas has updated the pull request incrementally with one
additional commit since the last revi
llptr` from the question if ObjectMonitorIterator
> is supported.
>
> Testing:
> * Passes all `serviceability/sa` tests
> * Currently running tier 1-3
> * Currently running GHA
Axel Boldt-Christmas has updated the pull request incrementally with one
additional commit sinc
On Mon, 18 Sep 2023 18:46:19 GMT, Chris Plummer wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Copyright changes too
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/r
On Mon, 18 Sep 2023 18:49:43 GMT, Chris Plummer wrote:
> > CDS tests are not happy with changing the class hierarchy of the
> > LingeredApp. Unless it is easily solved for the CDS test I will revert
> > those changes and have the 'TestObjectMonitorIterate' just do a less
> > precise check of a
llptr` from the question if ObjectMonitorIterator
> is supported.
>
> Testing:
> * Passes all `serviceability/sa` tests
> * Currently running tier 1-3
> * Currently running GHA
Axel Boldt-Christmas has updated the pull request incrementally with four
additional commits
On Mon, 18 Sep 2023 12:11:24 GMT, Axel Boldt-Christmas
wrote:
>> ObjectMonitorIterator fails to return the most resent monitor added. It
>> start with returning the `nextOM()` ObjectMonitor from the `_head`
>> ObjectMonitor but fails to ever return the `_head` ObjectMonit
llptr` from the question if ObjectMonitorIterator
> is supported.
>
> Testing:
> * Passes all `serviceability/sa` tests
> * Currently running tier 1-3
> * Currently running GHA
Axel Boldt-Christmas has updated the pull request incrementally with one
additional commit since the
On Wed, 20 Sep 2023 22:37:59 GMT, Chris Plummer wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Removed unnecessary comment
>
> src/jdk.hotspot.agent/share/c
llptr` from the question if ObjectMonitorIterator
> is supported.
>
> Testing:
> * Passes all `serviceability/sa` tests
> * Passed tier 1-5
> * Passed GHA
Axel Boldt-Christmas has updated the pull request incrementally with one
additional commit since the last revision:
Update copyright
On Tue, 19 Sep 2023 22:19:06 GMT, Chris Plummer wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Removed unnecessary comment
>
> test/hotspot/jtreg/run
On Thu, 21 Sep 2023 06:11:42 GMT, Axel Boldt-Christmas
wrote:
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/ObjectSynchronizer.java
>> line 86:
>>
>>> 84:
>>> 85: ObjectMonitorIterator() {
>>> 86: mon = new ObjectMoni
On Mon, 25 Sep 2023 02:08:36 GMT, David Holmes wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update copyright year
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/r
On Mon, 25 Sep 2023 03:40:53 GMT, David Holmes wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update copyright year
>
> test/hotspot/jtreg/serviceability/sa/TestObjectMonit
On Mon, 18 Sep 2023 09:54:18 GMT, Axel Boldt-Christmas
wrote:
> ObjectMonitorIterator fails to return the most resent monitor added. It start
> with returning the `nextOM()` ObjectMonitor from the `_head` ObjectMonitor
> but fails to ever return the `_head` ObjectMonitor.
>
On Thu, 21 Sep 2023 06:21:25 GMT, Axel Boldt-Christmas
wrote:
>> ObjectMonitorIterator fails to return the most resent monitor added. It
>> start with returning the `nextOM()` ObjectMonitor from the `_head`
>> ObjectMonitor but fails to ever return the `_head` ObjectMonit
On Fri, 27 Oct 2023 09:48:00 GMT, Leo Korinth wrote:
> Update method name after huge renaming conflict
Marked as reviewed by aboldtch (Reviewer).
Trivial fix.
-
PR Review: https://git.openjdk.org/jdk/pull/16395#pullrequestreview-1701406738
PR Comment: https://git.openjdk.org/jdk/p
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
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 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
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: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
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 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:
Rename and comment SystemDictionary::metho
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:
Cleanup soon
-
Chang
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
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
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 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
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 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
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
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, 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
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
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: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
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
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 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:
>
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-
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 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 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
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 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 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
1 - 100 of 162 matches
Mail list logo
