On Fri, 10 Jan 2025 07:30:04 GMT, Peter Levart wrote:
> [JDK-8169880](https://bugs.openjdk.org/browse/JDK-8169880) removed a
> debugging option to disable caching of reflective data in java.lang.Class,
> which had a consequence that now Class#reflectiveData method guarantees to
>
od were left intact
> and still contain null checks and branches that are never taken after this
> change. Some new callers were added later and they don't have null checks. I
> propose a patch to remove these unneeded null checks and never taken branches.
Peter Levart ha
[JDK-8169880](https://bugs.openjdk.org/browse/JDK-8169880) removed a debugging
option to disable caching of reflective data in java.lang.Class, which had a
consequence that now Class#reflectiveData method guarantees to return a
non-null result. Existing callers of that method were left intact an
On Thu, 11 Jan 2024 15:23:14 GMT, Jorn Vernee wrote:
>> Peter Levart has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> move special-case check for equal segments to the instance method (more
>> probable)
&
` as well as `srcToOffset` and
> `dstToOffset` are also equal.
>
> Am I right?
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
remove special-case check from instance method - test pending
-
Changes:
- all: ht
` as well as `srcToOffset` and
> `dstToOffset` are also equal.
>
> Am I right?
Peter Levart has updated the pull request incrementally with one additional
commit since the last revision:
move special-case check for equal segments to the instance method (more
probable)
--
I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It
returns `-1` (meaning that regions are equal) when passing the same instance of
MemorySegment as both `srcSegment` and `dstSegment` parameters regardless of
whether `srcFromOffset` and `dstFromOffset` as well as `srcToOff
On Mon, 20 Feb 2023 13:09:50 GMT, liach wrote:
>> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not
>> thread safe
>
> We don't fear calling the factory twice for benign races, as the distinct
> constructor factory instances are behaviorally the same.
>
> The true issu
On Mon, 9 Jan 2023 20:04:34 GMT, Christian Wimmer wrote:
>> The method `String.split` contains a fast-path when the regular expression
>> parameter is not really a regular expression, but just a single split
>> character.
>> This fast path vs. slow path check can be constant folded when the reg
On Mon, 9 Jan 2023 20:04:34 GMT, Christian Wimmer wrote:
>> The method `String.split` contains a fast-path when the regular expression
>> parameter is not really a regular expression, but just a single split
>> character.
>> This fast path vs. slow path check can be constant folded when the reg
On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG wrote:
> I/O had always been much slower than CPU and memory access, and thanks to
> physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory
> cache on or nearby a CPU core, the distance b
On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG wrote:
> I/O had always been much slower than CPU and memory access, and thanks to
> physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory
> cache on or nearby a CPU core, the distance b
On Fri, 23 Dec 2022 22:28:34 GMT, Markus KARG wrote:
> I/O had always been much slower than CPU and memory access, and thanks to
> physical constraints, always will be.
> While CPUs can get shrinked more and more, and can hold more and more memory
> cache on or nearby a CPU core, the distance b
On Tue, 16 Aug 2022 11:12:35 GMT, Alan Bateman wrote:
>> Change the test to use a custom scheduler so there is better control on when
>> the carrier threads terminates. Also convert test to TestNG so that all test
>> cases can be run in the context of a virtual thread.
>
> Alan Bateman has upda
On Wed, 10 Aug 2022 09:18:01 GMT, Alan Bateman wrote:
> Change the test to use a custom scheduler so there is better control on when
> the carrier threads terminates. Also convert test to TestNG so that all test
> cases can be run in the context of a virtual thread.
test/jdk/jdk/internal/misc/
On Wed, 10 Aug 2022 09:18:01 GMT, Alan Bateman wrote:
> Change the test to use a custom scheduler so there is better control on when
> the carrier threads terminates. Also convert test to TestNG so that all test
> cases can be run in the context of a virtual thread.
Now that we have control ov
On Sun, 7 Aug 2022 08:14:58 GMT, Alan Bateman wrote:
> > Sorry for joining late. I noticed that modsHashCode is a private method and
> > it takes Iterable as a parameter. But everywhere it is called, a Set is
> > passed to it. So why not just calling the set.hashCode() and be done with
> > it?
On Sun, 10 Jul 2022 10:20:31 GMT, Laurent Bourgès wrote:
>> iaroslavski has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>>
>> * Added JMH
>
> Here are JMH test results on m
On Thu, 4 Aug 2022 10:57:53 GMT, Peter Levart wrote:
> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s)
> when used internally in JDK for per-carrier-thread caches of native
> ByteBuffer(s) and NativeBuffer(s). If used from virtual thr
On Sat, 6 Aug 2022 08:08:43 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix
> https://bugs.openjdk.org/browse/JDK-8290041?
>
> As noted by the reporter, the current implementation is buggy since the
> calculation can result in a different value of the
On Sat, 6 Aug 2022 08:08:43 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to fix
> https://bugs.openjdk.org/browse/JDK-8290041?
>
> As noted by the reporter, the current implementation is buggy since the
> calculation can result in a different value of the
On Thu, 4 Aug 2022 15:55:38 GMT, Alan Bateman wrote:
>> Peter Levart has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Removed unused JLA, SharedSecrets, added @enablePreview test annotation
>
&
thread is terminated. Since it must wait for 30 seconds for that to
> happen, only one of the test cases is performed in this mode. The correct
> logic of TerminatingThreadLocal is still verified with all test-cases using
> platform threads that can be terminated more rapidly.
Peter Levart has
On Thu, 4 Aug 2022 15:54:29 GMT, Alan Bateman wrote:
>> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s)
>> when used internally in JDK for per-carrier-thread caches of native
>> ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such
>> TerminatingThre
On Thu, 4 Aug 2022 13:38:08 GMT, Peter Levart wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [d4a795d7](https://github.com/openjdk/jdk/commit/d4a795d75aef8d787934f5c05e146c61138a408a)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repositor
Hi all,
This pull request contains a backport of commit
[d4a795d7](https://github.com/openjdk/jdk/commit/d4a795d75aef8d787934f5c05e146c61138a408a)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Peter Levart on 4 Aug 2022 and
On Fri, 29 Jul 2022 09:05:53 GMT, Peter Levart wrote:
> This is a continuation of effort from
> https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching
> test which is failing with various GCs != G1. The test class contains 2 test
This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s)
when used internally in JDK for per-carrier-thread caches of native
ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such
TerminatingThreadLocal(s) are not registered with the carrier thread for the
clea
On Fri, 29 Jul 2022 09:38:13 GMT, Aleksey Shipilev wrote:
>> Peter Levart has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Nits from review comments
>
> test/jdk/java/io/ObjectStreamClass/ObjectStreamClass
On Wed, 3 Aug 2022 11:12:38 GMT, Aleksey Shipilev wrote:
>> Peter Levart has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add SerialGC variant
>
> test/jdk/java/io/ObjectStreamClass/ObjectStreamClassCaching
() instance. The "effectiveness" of caching
> is confirmed by verifying that weakly reachable new Object() referent of ref2
> is GC-ed earlier than softly reachable ObjectStreamClass referent of ref1.
> The test now contains several @run(s) with explicitly selected set of GC
> a
On Tue, 2 Aug 2022 18:03:14 GMT, Roman Kennke wrote:
> Does't it make sense to also test SerialGC? Other than that it looks good.
Added SerialGC variant and it passes the test.
-
PR: https://git.openjdk.org/jdk/pull/9684
() instance. The "effectiveness" of caching
> is confirmed by verifying that weakly reachable new Object() referent of ref2
> is GC-ed earlier than softly reachable ObjectStreamClass referent of ref1.
> The test now contains several @run(s) with explicitly selected set of GC
> a
On Fri, 29 Jul 2022 09:05:53 GMT, Peter Levart wrote:
> This is a continuation of effort from
> https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching
> test which is failing with various GCs != G1. The test class contains 2 test
On Tue, 2 Aug 2022 16:49:07 GMT, Сергей Цыпанов wrote:
>> Сергей Цыпанов has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8288327: Inline privateGetParameters()
>
> Let's wait a bit
@stsypanov Do you need a sponsor or are you waiting for
On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian wrote:
>> Please review this change to replace the finalizer in
>> `AbstractLdapNamingEnumeration` with a Cleaner.
>>
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult
>> res`, and `LdapClient enumClnt`) are moved to a
On Tue, 26 Jul 2022 05:26:31 GMT, Stuart Marks wrote:
> Hans Boehm wrote:
>
> > I also have concerns about the use of fullFence here. I believe it should
> > be the case that reachabilityFence guarantees visibility of memory
> > operations program-ordered before the reachabilityFence(p) to the
On Sat, 30 Jul 2022 11:07:25 GMT, Peter Levart wrote:
>> src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java
>> line 216:
>>
>>> 214: } finally {
>>> 215: // Ensure Cleaner does not run until afte
On Fri, 22 Jul 2022 20:51:59 GMT, Brent Christian wrote:
>> Please review this change to replace the finalizer in
>> `AbstractLdapNamingEnumeration` with a Cleaner.
>>
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult
>> res`, and `LdapClient enumClnt`) are moved to a
On Wed, 1 Jun 2022 21:40:43 GMT, Roger Riggs wrote:
> I don't think there is any benefit to the `try{} finally {fence}`. The
> reachabilityFence has no executable code. Its only purpose is to keep the
> reference in scope alive.
...reachability fence has no code, but puting it into finally blo
On Fri, 29 Jul 2022 09:05:53 GMT, Peter Levart wrote:
> This is a continuation of effort from
> https://github.com/openjdk/jdk/pull/9533 to fix the ObjectStreamClassCaching
> test which is failing with various GCs != G1. The test class contains 2 test
This is a continuation of effort from https://github.com/openjdk/jdk/pull/9533
to fix the ObjectStreamClassCaching test which is failing with various GCs !=
G1. The test class contains 2 test methods:
- test2CacheReleaseUnderMemoryPressure - this one was not logically changed at
all - just one m
On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java
>
On Thu, 28 Jul 2022 14:33:40 GMT, Aleksey Shipilev wrote:
>
> > It then basically tests just that newly constructed SoftReference is not
> > cleared in the next moment after construction.
>
> Yes, but not really. There is still a 100ms sleep and reference processing
> involved, which somewhat
On Wed, 27 Jul 2022 12:30:43 GMT, Aleksey Shipilev wrote:
>>> ...I can take this over, unless you want to do it, Aleksey?
>>
>> I find it dubious to try and guess what GCs would do with non-strong refs,
>> but feel free. Don't reassign the bug yet, just see how messy that would be?
>
>> > ...I
On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java
>
On Wed, 27 Jul 2022 12:30:43 GMT, Aleksey Shipilev wrote:
>>> ...I can take this over, unless you want to do it, Aleksey?
>>
>> I find it dubious to try and guess what GCs would do with non-strong refs,
>> but feel free. Don't reassign the bug yet, just see how messy that would be?
>
>> > ...I
On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java
>
On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java
>
On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java
>
On Mon, 25 Jul 2022 13:13:30 GMT, Aleksey Shipilev wrote:
> > Just a note that the failing test is not about checking that cache is
> > cleared after plain System.gc(), but about checking that cache is NOT
> > cleared after System.gc() when there was no real memory pressure. The cache
> > uses
On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java
>
On Mon, 18 Jul 2022 07:40:53 GMT, Aleksey Shipilev wrote:
> Test appears to pass fine with G1. But it fails with other GCs, for example
> Parallel, Shenandoah, etc, it fails:
>
>
> $ CONF=linux-x86_64-server-fastdebug make test
> TEST=java/io/ObjectStreamClass/ObjectStreamClassCaching.java
>
On Thu, 30 Jun 2022 12:08:19 GMT, Сергей Цыпанов wrote:
>> If there are two threads calling `Executable.hasRealParameterData()` under
>> race and the first one writes into volatile `Executable.parameters` field
>> (doing _releasing store_) and the second thread reads non-null value from
>> the
On Mon, 4 Jul 2022 10:06:12 GMT, Сергей Цыпанов wrote:
>> A more realistic use case would be something in the lines of checking
>> whether the method is an expected one:
>>
>>
>> @Benchmark
>> public boolean isFoo() {
>> return matches(method, "foo", int.class, String.class);
>> }
>>
On Mon, 4 Jul 2022 06:19:00 GMT, Peter Levart wrote:
>> hmm, is the faster getParameters (without explicit index access) a result of
>> the annotation? getParameter0 shows the documented effect but isn't quite
>> our use case here.
>
> ...neither is obtaining a
On Sun, 3 Jul 2022 20:12:13 GMT, liach wrote:
>> With `static` and without `@Stable` the benchmark yields
>>
>> BenchmarkMode Cnt Score Error Units
>> AccessParamsBenchmark.getParameter0 avgt 10 1,212 ± 0,083 ns/op
>> AccessParamsBenchmark.getParameters avg
On Fri, 1 Jul 2022 12:26:04 GMT, Сергей Цыпанов wrote:
>> ... I can only see the array being cloned and not accessed directly. I don't
>> belive cloning a @stable array is any different in JIT-ed code as cloning
>> normal "mutable" array unless JIT "sees" through it and scalarizes the
>> value
On Fri, 1 Jul 2022 10:38:53 GMT, Peter Levart wrote:
>> Right, in that case, it should remain.
>
> But, ... is any code path accessing the elements of the @Stable array by
> constant indexes? Only in that case would the annotation have any effect on
> the JIT-ed code. Oth
On Fri, 1 Jul 2022 10:35:11 GMT, Peter Levart wrote:
>> @plevart so should I remove it or keep as is?
>
> Right, in that case, it should remain.
But, ... is any code path accessing the elements of the @Stable array by
constant indexes? Only in that case would the annotation have a
On Thu, 30 Jun 2022 12:08:19 GMT, Сергей Цыпанов wrote:
>> If there are two threads calling `Executable.hasRealParameterData()` under
>> race and the first one writes into volatile `Executable.parameters` field
>> (doing _releasing store_) and the second thread reads non-null value from
>> the
On Fri, 1 Jul 2022 07:27:59 GMT, Сергей Цыпанов wrote:
>> src/java.base/share/classes/java/lang/reflect/Executable.java line 457:
>>
>>> 455: private transient @Stable ParameterData parameterData;
>>> 456:
>>> 457: record ParameterData(@Stable Parameter[] parameters, boolean
>>> isReal
On Thu, 30 Jun 2022 12:08:19 GMT, Сергей Цыпанов wrote:
>> If there are two threads calling `Executable.hasRealParameterData()` under
>> race and the first one writes into volatile `Executable.parameters` field
>> (doing _releasing store_) and the second thread reads non-null value from
>> the
63 matches
Mail list logo
