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)
>>
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:
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 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 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, 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 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 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
nullptr` 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 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
nullptr` 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 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
nullptr` 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 commi
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
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
nullptr` 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
nullptr` 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
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.
>
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 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/
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 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
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 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 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
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
ith 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
>
ith 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
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
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
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&
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 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 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
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
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 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
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
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
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
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 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
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
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 reques
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 request
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
ue, and 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
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
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 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
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 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
>>
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
57 matches
Mail list logo
