can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Fri, 18 Apr 2025 09:33:48 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> please review this change that implements (currently Draft) JEP: G1:
>> Improve Application Throughput with a More Efficient Write-Barrier.
>>
>> The reason for posting this early
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Wed, 9 Apr 2025 12:48:10 GMT, Thomas Schatzl wrote:
>> src/hotspot/cpu/x86/gc/g1/g1BarrierSetAssembler_x86.cpp line 101:
>>
>>> 99: }
>>> 100:
>>> 101: void
>>> G1BarrierSetAssembler::gen_write_ref_array_post_barrier(MacroAssembler*
&g
On Wed, 9 Apr 2025 22:24:10 GMT, Martin Doerr wrote:
> This PR needs an update for x86 platforms when merging:
> g1BarrierSetAssembler_x86.cpp:117:6: error: 'class MacroAssembler' has no
> member named 'get_thread'
I fixed this for now, but it will be broken again in just a bit with Aleksey's
On Thu, 10 Apr 2025 08:34:00 GMT, Aleksey Shipilev wrote:
> > I fixed this for now, but it will be broken again in just a bit with
> > Aleksey's ongoing removal of x86 32 bit platform efforts.
>
> I think all x86 cleanups related to GC and adjacent code have landed in
> mainline now. So I expe
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Tue, 8 Apr 2025 19:59:09 GMT, Albert Mingkun Yang wrote:
>> Thomas Schatzl has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 39 commits:
>>
>> - * missing file from merge
>> - Merge branch &#
On Wed, 9 Apr 2025 11:34:09 GMT, Roberto Castañeda Lozano
wrote:
>> Thomas Schatzl has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 39 commits:
>>
>> - * missing file from merge
>> - Merge bra
On Wed, 9 Apr 2025 11:35:26 GMT, Roberto Castañeda Lozano
wrote:
>> Thomas Schatzl has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 39 commits:
>>
>> - * missing file from merge
>> - Merge bra
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Thu, 20 Mar 2025 09:44:07 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> please review this change that implements (currently Draft) JEP: G1:
>> Improve Application Throughput with a More Efficient Write-Barrier.
>>
>> The reason for posting this early
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Wed, 19 Mar 2025 13:17:19 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> please review this change that implements (currently Draft) JEP: G1:
>> Improve Application Throughput with a More Efficient Write-Barrier.
>>
>> The reason for posting this early
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Wed, 12 Mar 2025 13:56:57 GMT, Thomas Schatzl wrote:
>> src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp line 263:
>>
>>> 261:
>>> 262: SuspendibleThreadSetLeaver sts_leave;
>>> 263: VMThread::execute(&op);
>>
>> Can you elabora
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Thu, 13 Mar 2025 13:07:29 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> please review this change that implements (currently Draft) JEP: G1:
>> Improve Application Throughput with a More Efficient Write-Barrier.
>>
>> The reason for posting this early
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Wed, 12 Mar 2025 13:20:25 GMT, Albert Mingkun Yang wrote:
>> Thomas Schatzl has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request cont
On Wed, 12 Mar 2025 12:23:50 GMT, Albert Mingkun Yang wrote:
>> Thomas Schatzl has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request cont
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Tue, 11 Mar 2025 03:22:52 GMT, Fei Yang wrote:
> Tier1-3 test good on linux-riscv64 platform. And I have prepared an add-on
> change which implements the barrier method to write cards for a reference
> array for this platform. Do you want to have it in this PR? Thanks.
I added your changes,
On Tue, 4 Mar 2025 10:46:13 GMT, Thomas Schatzl wrote:
> I got an error while testing java/foreign/TestUpcallStress.java on
> linuxaarch64 with this PR:
Fixed.
-
PR Comment: https://git.openjdk.org/jdk/pull/23739#issuecomment-2708458459
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Wed, 5 Mar 2025 10:41:02 GMT, Ivan Walulya wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> * fix whitespace
>> * additional whitespace between log tags
>>
On Tue, 4 Mar 2025 15:33:29 GMT, Albert Mingkun Yang wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> iwalulya review
>> * comments for variables tracking to-collection-set and j
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Tue, 4 Mar 2025 16:00:46 GMT, Thomas Schatzl wrote:
>> src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 116:
>>
>>> 114: SwapGlobalCT,// Swap global card table.
>>> 115: SwapJavaThreadsCT, // Swap java thread's card t
On Tue, 4 Mar 2025 16:04:00 GMT, Thomas Schatzl wrote:
>> src/hotspot/share/gc/g1/g1ConcurrentRefineThread.cpp line 219:
>>
>>> 217: // The young gen revising mechanism reads the predictor and the
>>> values set
>>> 218: // here. Av
On Tue, 4 Mar 2025 15:56:05 GMT, Thomas Schatzl wrote:
> It's fast anyway.
To clarify: If you have multiple refinement rounds between two garbage
collections, the time to clear the young gen cards is almost noise compared to
the actual refinement effort. Like two magnitude
On Tue, 4 Mar 2025 15:33:29 GMT, Albert Mingkun Yang wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> iwalulya review
>> * comments for variables tracking to-collection-set and j
On Tue, 4 Mar 2025 15:16:17 GMT, Albert Mingkun Yang wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> iwalulya review
>> * comments for variables tracking to-collection-set and j
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Tue, 4 Mar 2025 10:06:37 GMT, Ivan Walulya wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> * iwalulya review 2
>> * G1ConcurrentRefineWorkState -> G1ConcurrentRefineSw
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Tue, 4 Mar 2025 10:37:47 GMT, Martin Doerr wrote:
> I got an error while testing java/foreign/TestUpcallStress.java on
> linuxaarch64 with this PR:
>
> ```
> # Internal Error
> (/openjdk-jdk-linux_aarch64-dbg/jdk/src/hotspot/share/gc/g1/g1CardTable.cpp:56),
> pid=19044, tid=19159
> # gua
On Tue, 4 Mar 2025 09:52:40 GMT, Thomas Schatzl wrote:
>> src/hotspot/share/gc/g1/g1ConcurrentRefine.hpp line 84:
>>
>>> 82: // Tracks the current refinement state from idle to completion (and
>>> reset back
>>> 83: // to idle).
&g
On Mon, 3 Mar 2025 18:50:37 GMT, Ivan Walulya wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> * fix comment (trailing whitespace)
>> * another assert when snapshotting at a safep
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Tue, 4 Mar 2025 08:22:03 GMT, Thomas Schatzl wrote:
>> src/hotspot/share/gc/g1/g1ConcurrentRefineStats.hpp line 43:
>>
>>> 41: size_t _cards_clean;// Number of cards found clean.
>>> 42: size_t _cards_not_parsable; // Number of car
On Mon, 3 Mar 2025 15:19:20 GMT, Albert Mingkun Yang wrote:
> Can you elaborate on what the "special handling" would be, if we don's set
> "claimed" for non-committed regions?
the iteration code, would for every region check whether the region is actually
committed or not.
The `heap_region_it
On Mon, 3 Mar 2025 18:28:48 GMT, Ivan Walulya wrote:
> Why are we using a prediction here?
Quickly checking again, do we have the actual count here from somewhere?
> Additionally, won't this prediction also include cards from the old gen
> regions in case of mixed gcs? How do we reconcile that
On Mon, 3 Mar 2025 20:02:16 GMT, Ivan Walulya wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> * fix comment (trailing whitespace)
>> * another assert when snapshotting at a safep
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Mon, 3 Mar 2025 15:17:27 GMT, Albert Mingkun Yang wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> * fix comment (trailing whitespace)
>> * another assert when snapshotting a
On Mon, 3 Mar 2025 14:47:00 GMT, Albert Mingkun Yang wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> * fix comment (trailing whitespace)
>> * another assert when snapshotting a
On Mon, 3 Mar 2025 14:11:09 GMT, Albert Mingkun Yang wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> * fix comment (trailing whitespace)
>> * another assert when snapshotting a
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
On Thu, 27 Feb 2025 18:31:16 GMT, Albert Mingkun Yang wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> * remove unnecessarily added logging
>
> src/hotspot/share/gc/g1/g1Re
On Thu, 27 Feb 2025 12:07:29 GMT, Albert Mingkun Yang wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> * remove unnecessarily added logging
>
> src/hotspot/share/gc/g1/g1Concurrent
On Thu, 27 Feb 2025 18:24:15 GMT, Albert Mingkun Yang wrote:
>> Thomas Schatzl has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> * remove unnecessarily added logging
>
> src/hotspot/share/gc/g1/g1BarrierSet.
can decrease
> throughput by 10-20%
> ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is
> corroborated by some benchmarks (see links).
>
> The main idea for this change is to not use fine-grained synchronization
> between refinement and mutator threads, bu
Hi all,
please review this change that implements (currently Draft) JEP: G1: Improve
Application Throughput with a More Efficient Write-Barrier.
The reason for posting this early is that this is a large change, and the JEP
process is already taking very long with no end in sight but we would
On Mon, 19 Feb 2024 09:34:12 GMT, Jaikiran Pai wrote:
> Can I get a review of this change which fixes the copyright header on
> `DeflaterDictionaryTests.java`?
Ship it.
-
Marked as reviewed by tschatzl (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17911#pullrequestrevie
Hi,
since this looks like a suggestion for a change to the libraries
similar to the mentioned JDK-6805775, and not actually GC, cc'ing the
core-libs-dev mailing list.
Hth,
Thomas
On 07.02.24 15:20, Frank Kretschmer wrote:
Hi Java GC-experts,
I'm facing an interesting G1 garbage collect
On Wed, 10 Jan 2024 12:09:07 GMT, Stefan Karlsson wrote:
> TestGCLockerWithShenandoah.java was recently removed, but the TEST.groups
> file still has a reference to it. This causes problems in our CI pipeline.
lgtm.
-
Marked as reviewed by tschatzl (Reviewer).
PR Review: https://
On Thu, 30 Nov 2023 20:59:01 GMT, Jorn Vernee wrote:
> Need to use `jlong_to_ptr` instead of raw cast.
>
> I've also fixed another latent issue in `CLayouts` where we were initializing
> `C_LONG_LONG` with the `long` layout. This was resulting in a class cast
> exception when running the XorTe
On Fri, 30 Jun 2023 08:11:47 GMT, Matthias Baesken wrote:
> Most G1 tests set -XX:+UseG1GC, but a few (e.g.
> gc/g1/TestVerificationInConcurrentCycle.java) miss that.
> This is usually just fine and no problem because G1 is the default anyway.
> However in some cases, where a custom JVM changes
Hi,
On 03.03.23 19:02, Aleksei Ivanov wrote:
> Hello,
>
> In clientlibs, there's occasionally a need to verify an object isn't
> leaked. For this purpose, WeakReference or PhantomReference is used.
>
> Then, we need to make the reference object be cleared, so a GC cycle
> need to be triggered. Th
77 matches
Mail list logo
