On Tue, 21 May 2024 13:49:18 GMT, jengebr wrote:
> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
> Class[0] instances. This cloning is intended to prevent callers from
> changing array contents, but smany Methods have zero exceptions or zero
> parameters, and ret
On Wed, 22 May 2024 19:48:49 GMT, Chen Liang wrote:
>> I really see no reason to try and save on re-use of this one-line method for
>> _everything_. In fact, I do not quite see a very compelling reason to even
>> have the utility method. Sharing the code between `Method` and `Constructor`
>> i
On Wed, 22 May 2024 14:32:23 GMT, Chen Liang wrote:
>> Thanks. Unfortunately the variable `cloneArray` is actually a method
>> parameter, and most of the callers pass in `false` - so using this utility
>> method to control cloning would actually introduce cloning in several places
>> where it
On Tue, 21 May 2024 13:49:18 GMT, jengebr wrote:
> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
> Class[0] instances. This cloning is intended to prevent callers from
> changing array contents, but smany Methods have zero exceptions or zero
> parameters, and ret
On Fri, 31 May 2024 16:21:36 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but smany Methods have zero exceptions or zero
>> parameters, and
On Fri, 31 May 2024 17:59:18 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Fri, 31 May 2024 18:39:33 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Fri, 31 May 2024 18:39:33 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Mon, 3 Jun 2024 16:47:20 GMT, jengebr wrote:
> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
> cloning of Object[0] instances. This cloning is intended to prevent callers
> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
> to size z
On Wed, 5 Jun 2024 19:21:56 GMT, Jorn Vernee wrote:
> These 4 tests were failing due to an incompatibility with jcstress. They were
> problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
>
> Now that jcstress has been updated
> (https://github.com/openjdk/jdk/pull/19332) with t
On Wed, 5 Jun 2024 14:56:26 GMT, jengebr wrote:
> clone() performs a shallow copy, so there is currently no Object[] allocated
> and therefore nothing to optimize.
Yes, I believe so.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19527#discussion_r1629666551
On Thu, 6 Jun 2024 12:46:36 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to si
On Wed, 5 Jun 2024 19:21:56 GMT, Jorn Vernee wrote:
> These 4 tests were failing due to an incompatibility with jcstress. They were
> problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
>
> Now that jcstress has been updated
> (https://github.com/openjdk/jdk/pull/19332) with t
On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak wrote:
>> Improve the speed of Method.hashCode by caching the hashcode on first use.
>> I've seen an application where Method.hashCode is a hot path, and this is a
>> fairly simple speedup. The memory overhead is low.
>>
>> This addresses issue
>
On Thu, 6 Jun 2024 12:46:36 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to si
I was auditing the current uses of `@Stable` before relaxing its barriers
([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an
easy spot.
`resolvedEnum` is not `final`. So technically publishing the object via data
race can show `resolvedEnum` as `null`, which would bre
On Thu, 27 Jun 2024 19:30:34 GMT, Aleksey Shipilev wrote:
> I was auditing the current uses of `@Stable` before relaxing its barriers
> ([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an
> easy spot.
>
> `resolvedEnum` is not `final`. So technically
On Thu, 27 Jun 2024 19:30:34 GMT, Aleksey Shipilev wrote:
> I was auditing the current uses of `@Stable` before relaxing its barriers
> ([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an
> easy spot.
>
> `resolvedEnum` is not `final`. So technically
On Tue, 11 Jun 2024 08:58:34 GMT, Aleksey Shipilev wrote:
>> Sean Gwizdak 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 conta
On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev wrote:
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a pe
[JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
method for `Reference.clear`. The original patch skipped intrinsification of
this method, because we thought `Reference.clear` is not on a performance
sensitive path. However, it shows up prominently on simple benchmarks
On Fri, 12 Jul 2024 10:16:13 GMT, Erik Österlund wrote:
> The reason we did not do this before is that this is not a strong reference
> store. Strong reference stores with a SATB collector will keep the referent
> alive, which is typically the exact opposite of what a user wants when they
> cl
On Fri, 12 Jul 2024 11:57:56 GMT, Erik Österlund wrote:
> The runtime use of the Access API knows how to resolve an unknown oop ref
> strength using AccessBarrierSupport::resolve_unknown_oop_ref_strength.
> However, we do not have support for that in the C2 backend. In fact, it does
> not unde
On Mon, 15 Jul 2024 01:45:57 GMT, Chen Liang wrote:
> The `@Stable` on the `index` field is incorrect, as stable only avoids
> inlining `0`. Solution is to use bit flip on the actual index (and rename the
> field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0
> the defaul
On Mon, 15 Jul 2024 12:28:51 GMT, Chen Liang wrote:
> Indeed, for some reason I thought the range of short is -256 to 255 instead
> of -65536 to 65535
Yeah, I thought something like this was going on; it would be a smart way to
leverage that negative side in two-complement form is one value la
On Thu, 20 Jun 2024 19:17:25 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to s
On Mon, 15 Jul 2024 14:09:22 GMT, Chen Liang wrote:
>> The `@Stable` on the `index` field is incorrect, as stable only avoids
>> inlining `0`. Solution is to use bit flip on the actual index (and rename
>> the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and
>> 0 the de
On Mon, 15 Jul 2024 15:47:50 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 778:
>>
>>> 776: var newParameters = new TreeMap(new
>>> Comparator<>() {
>>> 777: public int compare(Name n1, Name n2) {
>>> 778: r
On Mon, 15 Jul 2024 15:57:30 GMT, Chen Liang wrote:
>> The `@Stable` on the `index` field is incorrect, as stable only avoids
>> inlining `0`. Solution is to use bit flip on the actual index (and rename
>> the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and
>> 0 the de
On Mon, 15 Jul 2024 13:39:02 GMT, Aleksey Shipilev wrote:
>> Indeed, for some reason I thought the range of short is -256 to 255 instead
>> of -65536 to 65535
>
>> Indeed, for some reason I thought the range of short is -256 to 255 instead
>> of -65536 to 65535
>
gt; intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `all`
> - [ ] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a
On Fri, 12 Jul 2024 13:19:31 GMT, Aleksey Shipilev wrote:
>>> > The reason we did not do this before is that this is not a strong
>>> > reference store. Strong reference stores with a SATB collector will keep
>>> > the referent alive, which is typical
On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev wrote:
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a pe
gt; intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `all`
> - [x] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull request incrementally with one additional
commit
On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee wrote:
> This test spawns 2 forked processes, which then try to trigger a code cache
> OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty
> slow, which increases dramatically with `-Xcomp`, since startup Java code has
> to b
On Wed, 7 Aug 2024 19:26:59 GMT, Roger Riggs wrote:
> The original test fails intermittently, the reproducer failed consistently.
> With the fix, the failure was not observed in the test or reproducer.
>
> In jdk.internal.util.ReferencedKeyMap.entrySet() and toString() methods,
> avoid removing
On Wed, 7 Aug 2024 19:26:59 GMT, Roger Riggs wrote:
> The original test fails intermittently, the reproducer failed consistently.
> With the fix, the failure was not observed in the test or reproducer.
>
> In jdk.internal.util.ReferencedKeyMap.entrySet() and toString() methods,
> avoid removing
On Thu, 20 Jun 2024 19:17:25 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to s
On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is no
Problemlist-ing this tier2 test due to
[JDK-8294519](https://bugs.openjdk.org/browse/JDK-8294519).
Additional testing:
- [x] Linux x86_64 fastdebug, test is now skipped
-
Commit messages:
- Fix
Changes: https://git.openjdk.org/jdk/pull/10465/files
Webrev: https://webrevs.openjdk
On Wed, 28 Sep 2022 11:24:11 GMT, Aleksey Shipilev wrote:
> Problemlist-ing this tier2 test due to
> [JDK-8294519](https://bugs.openjdk.org/browse/JDK-8294519).
>
> Additional testing:
> - [x] Linux x86_64 fastdebug, test is now skipped
Thanks, I am integrating to g
On Wed, 28 Sep 2022 11:24:11 GMT, Aleksey Shipilev wrote:
> Problemlist-ing this tier2 test due to
> [JDK-8294519](https://bugs.openjdk.org/browse/JDK-8294519).
>
> Additional testing:
> - [x] Linux x86_64 fastdebug, test is now skipped
This pull request has now been integra
On Thu, 29 Sep 2022 13:11:03 GMT, Raffaello Giulietti
wrote:
> This fixes misleading indentations, which allows enabling the (currently
> disabled) `misleading-indentation` warning flag on two `.gmk` files.
This looks okay, but let's wait for #10426 to integrate first?
-
PR: http
On Mon, 3 Oct 2022 09:45:23 GMT, Raffaello Giulietti
wrote:
> Fixes sign extension propagation to higher bits.
This looks good! Remarkably, SonarCloud reports the bug on this line ("Prevent
"int" promotion by adding '& 0xff' to this expression"), but I skipped it when
generating the reports,
On Wed, 5 Oct 2022 10:02:49 GMT, Raffaello Giulietti
wrote:
>> This fixes misleading indentations, which allows enabling the (currently
>> disabled) `misleading-indentation` warning flag on two `.gmk` files.
>
> Raffaello Giulietti has updated the pull request with a new target base due
> to a
On Wed, 5 Oct 2022 12:01:00 GMT, Raffaello Giulietti
wrote:
>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 298:
>>
>>> 296: HEADERS_FROM_SRC := $(LIBLCMS_HEADERS_FROM_SRC), \
>>> 297: DISABLED_WARNINGS_gcc := format-nonliteral type-limits \
>>> 298: undef unused-functi
On Wed, 5 Oct 2022 13:46:23 GMT, Raffaello Giulietti
wrote:
>> I am not completely sure all `misleading-indentation` warnings are fixed in
>> Awt2d, this would require some more testing. I'd defer that to #10453.
>
> Awt2dLibraries.gmk in https://github.com/openjdk/jdk/pull/10453 seems more
>
On Wed, 5 Oct 2022 14:06:21 GMT, Raffaello Giulietti
wrote:
>> This fixes misleading indentations, which allows enabling the (currently
>> disabled) `misleading-indentation` warning flag on two `.gmk` files.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> addition
On Mon, 10 Oct 2022 23:16:20 GMT, Mandy Chung wrote:
> This separates `@run` into its own `@test` that they can be run concurrently.
I did consider when working on `VarHandle` tests recently, but figured this
split penalizes the total CPU time quite significantly. Given that these tests
run in
On Tue, 11 Oct 2022 11:31:51 GMT, Alan Bateman wrote:
> I wouldn't expect it to change the execution time of tier1_part1
I have *seen* the change in total CPU time when I tried to do the same thing
this PR does. This is why I bailed on doing the same thing PR proposes. Cutting
out the tests in
On Fri, 28 Oct 2022 07:19:31 GMT, Jie Fu wrote:
>> Hi all,
>>
>> As discussed here
>> https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it
>> would be better to add the vector api tests in GHA.
>>
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull reques
On Thu, 3 Nov 2022 03:31:56 GMT, Jie Fu wrote:
>> Hi all,
>>
>> As discussed here
>> https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it
>> would be better to add the vector api tests in GHA.
>>
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request
ter the benchmark -- no leftovers
Aleksey Shipilev 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 contains three additional
commits since the last revision:
On Wed, 9 Nov 2022 09:00:14 GMT, Aleksey Shipilev wrote:
> $ java -jar
> ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar
> org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s
> ...
>
> $ ls
> Apan.class
> ```
>
> Additional te
On Tue, 15 Nov 2022 13:53:23 GMT, Aleksey Shipilev wrote:
>> $ java -jar
>> ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar
>> org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s
>> ...
>>
>> $ ls
>> Apan.class
&
On Tue, 15 Nov 2022 13:53:23 GMT, Aleksey Shipilev wrote:
>> $ java -jar
>> ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar
>> org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s
>> ...
>>
>> $ ls
>> Apan.class
&
On Wed, 9 Nov 2022 09:00:14 GMT, Aleksey Shipilev wrote:
> $ java -jar
> ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar
> org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s
> ...
>
> $ ls
> Apan.class
> ```
>
> Additional te
[JDK-8271820](https://bugs.openjdk.org/browse/JDK-8271820) introduced the
`@Stable private Boolean callerSensitive;` cache in `Method`. That field is
essentially a tri-state `Boolean` that relies on its `null` value to serve as
"not initialized" value for `@Stable`.
This works well when the hol
e
> WrapperConstness.constant avgt 25 0.410 ± 0.010 ns/op
> WrapperConstness.nonConstant avgt 25 7.283 ± 0.025 ns/op
>
> # Patched
> WrapperConstness.constant avgt5 0.407 ± 0.008 ns/op
> WrapperConstness.nonConstant avgt5 7.054 ± 0.027 ns/op ; -3
On Wed, 30 Nov 2022 07:54:59 GMT, Alan Bateman wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add a newline
>
> src/java.base/share/classes/java/lang/reflect/Method.java
On Tue, 29 Nov 2022 19:39:02 GMT, Aleksey Shipilev wrote:
> [JDK-8271820](https://bugs.openjdk.org/browse/JDK-8271820) introduced the
> `@Stable private Boolean callerSensitive;` cache in `Method`. That field is
> essentially a tri-state `Boolean` that relies on its `null` value to
] Ad-hoc timing tests (see above)
> - [x] Reproducer from
> [CODETOOLS-7903331](https://bugs.openjdk.org/browse/CODETOOLS-7903331)
> - [x] Eyeballing the test results on passing tests with REPEAT_COUNT > 1
> - [x] Eyeballing the test results on intermittently failing tests with
On Wed, 4 Jan 2023 01:40:36 GMT, Jaikiran Pai wrote:
> Please update the copyright years on the files before integrating.
Updated.
> I see that in the additional testing section you note, running tests with
> RETRY_COUNT. Is that intentional? Does retry count play a role in the report
> gener
On Wed, 4 Jan 2023 14:41:20 GMT, Viktor Klang wrote:
> Currently Set.copyOf allocates both a HashSet and a new empty array when the
> input collection is empty.
>
> This patch avoids allocating anything for the case where the parameter
> collection's isEmpty returns true.
Looks okay. This rel
On Wed, 4 Jan 2023 09:15:18 GMT, Aleksey Shipilev wrote:
>> This should help to speed up tests significantly. Currently, if we run "make
>> test" with a subset of tests, JTReg would still read the entirety of test
>> root to report on tests that were not run. Even
On Tue, 3 Jan 2023 09:39:59 GMT, Aleksey Shipilev wrote:
> This should help to speed up tests significantly. Currently, if we run "make
> test" with a subset of tests, JTReg would still read the entirety of test
> root to report on tests that were not run. Even with cur
On Sun, 8 Jan 2023 23:25:36 GMT, David Holmes wrote:
> Committing unchanged files, other than a copyright year change, looks very
> odd here. Why was the SunMisUnsafe template updated but none of the tests
> actually changed?
`X-UnsafeAccessTest.java.template` generates both `SunMisc*` and
`J
On Mon, 16 Jan 2023 06:38:35 GMT, Feilong Jiang wrote:
>> Add experimental Foreign Function & Memory API support for RISC-V.
>>
>> For details of the FFM API RISC-V port please refer to [JBS
>> issue](https://bugs.openjdk.org/browse/JDK-8293841)
>>
>> Testing:
>>
>> - [x] jdk_foreign with rel
Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The
documentation for that method clearly says the precision and accuracy are
dependent on the underlying system behavior. However, it always rounds up
`nanos` to 1ms when doing the actual sleep. This means users cannot do t
On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev wrote:
> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The
> documentation for that method clearly says the precision and accuracy are
> dependent on the underlying system behavior. However, it always
On Wed, 29 Mar 2023 16:48:41 GMT, David M. Lloyd wrote:
> Are there specific factors which would make it unreasonable to implement
> `sleep` in terms of `parkNanos`?
After reading the Javadoc for `LockSupport`, I don't believe implementing
`Thread.sleep` with `LockSupport.parkNanos` is a prope
On Wed, 29 Mar 2023 18:10:30 GMT, Alan Bateman wrote:
>> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The
>> documentation for that method clearly says the precision and accuracy are
>> dependent on the underlying system behavior. However, it always rounds up
>> `nan
On Mon, 3 Apr 2023 09:36:39 GMT, David Holmes wrote:
>> We have the strange situation where calling `t.isAlive()` on a
>> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
>> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
>> its `JavaThread` pointe
On Mon, 3 Apr 2023 12:32:35 GMT, David Holmes wrote:
> > This looks interesting. I think it is time to rename eetop to
> > javaThreadAddr ...
>
> Feel free to file a RFE but not as part of this PR. :)
Well, when this thing is considered in isolation, it changes the clear
`isAlive0()` call to
On Mon, 3 Apr 2023 22:41:44 GMT, David Holmes wrote:
>> We have the strange situation where calling `t.isAlive()` on a
>> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
>> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
>> its `JavaThread` pointe
On Wed, 5 Apr 2023 07:23:03 GMT, David Holmes wrote:
>> We have the strange situation where calling `t.isAlive()` on a
>> `java.lang.Thread` `t`, will call into the VM (via `alive()` then
>> `isAlive0()`) where the VM then examines the `eetop` field of `t` to extract
>> its `JavaThread` pointe
On Wed, 5 Apr 2023 10:47:17 GMT, Matthias Baesken wrote:
> On Alpine Linux, using gcc12, we run now into this compile warning as error :
> In file included from
> /openjdk/linuxmuslx86_64/jdk/test/jdk/java/io/File/libGetXSpace.c:31:
> /usr/include/sys/errno.h:1:2: error: #warning redirecting inc
On Mon, 17 Apr 2023 12:14:55 GMT, Pavel Rappo wrote:
>> Improve the speed of Enum.hashCode by caching the identity hashcode on first
>> use. I've seen an application where Enum.hashCode is a hot path, and this is
>> fairly simple speedup. The memory overhead is low; in enums with no extra
>> f
On Mon, 17 Apr 2023 12:58:57 GMT, Aleksey Shipilev wrote:
>> src/java.base/share/classes/java/lang/Enum.java line 175:
>>
>>> 173: *
>>> 174: * @implNote Once initialized, the field value does not change.
>>> 175: * Hotspot's identity
On Mon, 17 Apr 2023 13:45:16 GMT, Pavel Rappo wrote:
>> It would not break the code functionally if that invariant ever breaks: we
>> would "just" call the (intrinsic) method on zero hash code. That `implNote`
>> only shows that it would not happen with current implementation at all.
>
> From t
On Mon, 17 Apr 2023 15:54:30 GMT, olivergillespie wrote:
>> Improve the speed of Enum.hashCode by caching the identity hashcode on first
>> use. I've seen an application where Enum.hashCode is a hot path, and this is
>> fairly simple speedup. The memory overhead is low; in enums with no extra
On Mon, 17 Apr 2023 15:41:34 GMT, olivergillespie wrote:
>> Yes, it is a bit strange to see @implNote here as this is a private field
>> that isn't going to show up in the javadoc. The javadoc for non-transient
>> fields in Serializable classes does show up in the Serialized Form page but
>> t
On Mon, 17 Apr 2023 16:42:38 GMT, olivergillespie wrote:
>> Improve the speed of Enum.hashCode by caching the identity hashcode on first
>> use. I've seen an application where Enum.hashCode is a hot path, and this is
>> fairly simple speedup. The memory overhead is low; in enums with no extra
On Mon, 17 Apr 2023 23:38:31 GMT, John R Rose wrote:
> I do have one comment: Since identity hash codes are typically reasonably
> well-conditioned, it is perfectly reasonable to recondition an occasional 0
> by replacing it with 1, in order to store it in a stable variable for later
> reuse.
On Tue, 18 Apr 2023 04:49:46 GMT, ExE Boss wrote:
>> Saves the virtual call, makes for a simpler intrinsic path (no need to
>> handle NPE and fold away, for example), since we know the super-class is
>> already `java.lang.Object`. Unless I miss something else here...
>
> Shouldn’t `invokespecia
On Mon, 17 Apr 2023 21:12:58 GMT, Jorn Vernee wrote:
> (if anything, using the ordinal would be _more_ stable, since it is only
> affected by the order of the constants, rather than by other code that runs
> before the identity hash code is generated).
Here lies the major original concern -- t
dditional testing:
> - [x] New regression test
> - [x] New benchmark
> - [x] Linux x86_64 `tier1`
> - [x] Linux AArch64 `tier1`
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains ten commits:
- Merge bra
On Wed, 12 Apr 2023 07:44:38 GMT, Alan Bateman wrote:
>> Aleksey Shipilev has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains ten commits:
>>
>> - Merge branch 'master' into JDK-83050920-thread-
On Thu, 30 Mar 2023 01:26:36 GMT, David Holmes wrote:
>> Aleksey Shipilev has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains ten commits:
>>
>> - Merge branch 'master' into JDK-83050920-thread-
On Wed, 29 Mar 2023 19:57:46 GMT, Alan Bateman wrote:
>> Yes, let me fix that. `TimeUnit.toNanos` handles it well itself, it seems.
>
>> Yes, let me fix that. `TimeUnit.toNanos` handles it well itself, it seems.
>
> This code is refactored in PR 13203 so we'll have to merge at some point.
Merge
On Tue, 18 Apr 2023 17:23:54 GMT, ExE Boss wrote:
>> `super.hashCode()` is a virtual call. `System.identityHashCode` is the
>> static call. I don't understand where `invokespecial` enters the picture
>> here.
>
> `invokespecial` is used to call instance methods in a non‑virtual manner.
>
> ---
On Tue, 18 Apr 2023 19:23:59 GMT, Viktor Klang wrote:
> In such a case, would it not be "better" to base the HC on
> getClass().getName().hashCode() which is specced and stable mixed with the
> ordinal to improve distribution over the 32-bit space?
Maybe, even though it still raises lots of co
dditional testing:
> - [x] New regression test
> - [x] New benchmark
> - [x] Linux x86_64 `tier1`
> - [x] Linux AArch64 `tier1`
Aleksey Shipilev has updated the pull request incrementally with one additional
commit since the last revision:
Fix gtests
-
Changes:
On Wed, 19 Apr 2023 05:50:00 GMT, David Holmes wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix gtests
>
> test/jdk/java/lang/Thread/SleepSanity.java line 75:
>
>&g
On Wed, 19 Apr 2023 08:15:44 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/java/lang/Thread.java line 576:
>>
>>> 574: long millis = NANOSECONDS.toMillis(nanos);
>>> 575: nanos -= MILLISECONDS.toNanos(millis);
>>> 576: sleep(millis, (int)nanos);
>>
>> This doub
On Wed, 19 Apr 2023 06:12:02 GMT, David Holmes wrote:
>> Hmmm I changed that comment ...
>
> My actual comment was changed to:
>> I suggest extending the comment to add
>
> This is how Thread.sleep(millis, nanos) has always behaved with only
> millisecond granularity.
Reworded, added comment.
On Wed, 19 Apr 2023 05:58:35 GMT, David Holmes wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix gtests
>
> src/hotspot/os/windows/os_windows.cpp line 5259:
>
>> 5257:
On Wed, 19 Apr 2023 05:58:11 GMT, David Holmes wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix gtests
>
> src/hotspot/os/windows/os_windows.cpp line 5253:
>
>
On Wed, 19 Apr 2023 06:14:37 GMT, David Holmes wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix gtests
>
> src/hotspot/os/posix/os_posix.cpp line 1545:
>
>> 1543:
dditional testing:
> - [x] New regression test
> - [x] New benchmark
> - [x] Linux x86_64 `tier1`
> - [x] Linux AArch64 `tier1`
Aleksey Shipilev has updated the pull request incrementally with six additional
commits since the last revision:
- Adjust assert
- Replace (park|sleep)_
1 - 100 of 702 matches
Mail list logo
