On Wed, 10 Sep 2025 11:38:38 GMT, Thomas Schatzl wrote:
> I can argue I was following precedent :)
You were, but it's a precedent that needs to die.
> I see your point though. What do you suggest to do here? Use `count`
> throughout instead?
Yes, although it might need a couple more comments.
On Wed, 10 Sep 2025 07:56:42 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 is that this is a large change, and the
On Fri, 12 Sep 2025 08:27:01 GMT, Martin Doerr wrote:
> Other idea: set count = noreg to prevent usage after it is used under the
> other name.
That wouldn't have solved the aliasing problem, because count and end were
being used as aliases for a register in _the same instruction_!
--
On Mon, 15 Sep 2025 07:18:14 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 is that this is a large change, and the
On Wed, 9 Jul 2025 01:23:43 GMT, Xiaohong Gong wrote:
>> ### Background
>> On AArch64, the minimum vector length supported is 64-bit for basic types,
>> except for `byte` and `boolean` (32-bit and 16-bit respectively to match
>> special Vector API features). This limitation prevents intrinsific
On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley wrote:
> Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache
> when searching for a binding. Neither do they update the cache when a binding
> is found.
> While this issue does not affect spec compliance, it i
On Mon, 7 Jul 2025 12:36:40 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 is that this is a large change, and the
On Mon, 7 Jul 2025 16:33:22 GMT, Chen Liang wrote:
> Can `get` and `slowGet` be refactored to use this `findBinding` too?
Not really, no. Inlining is critical here, and `get()` is written in this way
for efficiency of generated code.
-
PR Comment: https://git.openjdk.org/jdk/pull
On Mon, 7 Jul 2025 16:13:08 GMT, Andrew Haley wrote:
> Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache
> when searching for a binding. Neither do they update the cache when a binding
> is found.
> While this issue does not affect spec compliance, it i
Neither `ScopedValue.orElse` nor `ScopedValue.orElseThrow` consult the cache
when searching for a binding. Neither do they update the cache when a binding
is found.
While this issue does not affect spec compliance, it is surprising to users
that `x.orElse(other)` should be slower than `x.isBound
On Fri, 27 Jun 2025 14:32:11 GMT, Andrew Haley wrote:
> Scoped values cannot be used early in the JDK boot process because of some
> dependencies on System.getProperty(). This dependency should be removed in a
> way that allows scoped values to be created (but not necessarily bound)
On Thu, 3 Jul 2025 06:10:28 GMT, Xiaohong Gong wrote:
>> ### Background
>> On AArch64, the minimum vector length supported is 64-bit for basic types,
>> except for `byte` and `boolean` (32-bit and 16-bit respectively to match
>> special Vector API features). This limitation prevents intrinsific
alue's constructor has a synchronized block, which limits the
> use of scoped values at runtime. Constructing a scoped value should be a
> thread-local operation.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Little th
On Wed, 2 Jul 2025 02:39:33 GMT, Xiaohong Gong wrote:
>> ### Background
>> On AArch64, the minimum vector length supported is 64-bit for basic types,
>> except for `byte` and `boolean` (32-bit and 16-bit respectively to match
>> special Vector API features). This limitation prevents intrinsific
alue's constructor has a synchronized block, which limits the
> use of scoped values at runtime. Constructing a scoped value should be a
> thread-local operation.
Andrew Haley has updated the pull request incrementally with two additional
commits since the last revision:
-
On Mon, 30 Jun 2025 15:55:03 GMT, Alan Bateman wrote:
> There's something a bit uncomfortable about initializing hashGenerator in
> ScopedValue's class initializer, then changing it in Constants class
> initializer. Iimmediately clear what the memory model issues. It doesn't of
> course matter
On Tue, 1 Jul 2025 05:59:15 GMT, Xiaohong Gong wrote:
> ### Background
> On AArch64, the minimum vector length supported is 64-bit for basic types,
> except for `byte` and `boolean` (32-bit and 16-bit respectively to match
> special Vector API features). This limitation prevents intrinsificatio
On Fri, 27 Jun 2025 15:44:16 GMT, Chen Liang wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move THREAD_LOCAL_RANDOM_ACCESS into class Cache.Constants
>
> src/java.base/share/clas
alue's constructor has a synchronized block, which limits the
> use of scoped values at runtime. Constructing a scoped value should be a
> thread-local operation.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Move TH
alue's constructor has a synchronized block, which limits the
> use of scoped values at runtime. Constructing a scoped value should be a
> thread-local operation.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
On Fri, 27 Jun 2025 15:12:57 GMT, Chen Liang wrote:
> I looked at the existing code: the reason ScopedValue creation requires
> getProperty in Cache is that `generateKey` uses `Cache.primarySlot(x)` and
> `Cache.secondarySlot(x)`. Why did you choose to factor out `getProperty` into
> a new cla
Scoped values cannot be used early in the JDK boot process because of some
dependencies on System.getProperty(). This repen dency should be removed in a
way that allows scoped values to be created (but not necessarily bound) at any
stage during boot.
Also, Scoped Value's constructor has a synch
On Tue, 27 May 2025 12:03:41 GMT, Per Minborg wrote:
>> This PR builds on a concept John Rose told me about some time ago. Instead
>> of combining memory operations of various sizes, a single large and skewed
>> memory operation can be made to clean up the tail of remaining bytes.
>>
>> This h
On Mon, 28 Apr 2025 14:32:04 GMT, Andrew Haley wrote:
> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a
> null argument.
This pull request has now been integrated.
Changeset: 4e1878ca
Author: Andrew Haley
URL:
On Thu, 15 May 2025 16:03:44 GMT, Andrew Haley wrote:
>> This intrinsic is generally faster than the current implementation for
>> Panama segment operations for all writes larger than about 8 bytes in size,
>> increasing to more than 2* the performance on larger memory blocks
> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a
> null argument.
Andrew Haley has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 11 commits:
- Merge from
On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley wrote:
> This intrinsic is generally faster than the current implementation for Panama
> segment operations for all writes larger than about 8 bytes in size,
> increasing to more than 2* the performance on larger memory blocks on
>
nama false 262143 avgt 10 8345.300 ±
> 80.161 ns/op
> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ±
> 0.180 ns/op
> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ±
> 0.232 ns/op
Andrew Haley has updated the pull re
On Wed, 14 May 2025 15:36:32 GMT, Andrew Dinn wrote:
> Looks good to me.
Sorry, please approve again.
-
PR Comment: https://git.openjdk.org/jdk/pull/25147#issuecomment-2884310593
nama false 262143 avgt 10 8345.300 ±
> 80.161 ns/op
> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ±
> 0.180 ns/op
> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ±
> 0.232 ns/op
Andrew Haley has updated the pull re
nama false 262143 avgt 10 8345.300 ±
> 80.161 ns/op
> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ±
> 0.180 ns/op
> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ±
> 0.232 ns/op
Andrew Haley has updated the p
On Mon, 12 May 2025 09:39:48 GMT, Andrew Haley wrote:
> > Looking at the improvements made, I suggest we also change (in
> > `SegmentBulkOperations`):
> > ```
> > private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill",
> > Architectur
nama false 262143 avgt 10 8345.300 ±
> 80.161 ns/op
> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ±
> 0.180 ns/op
> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ±
> 0.232 ns/op
Andrew Haley has updated the pull req
nama false 262143 avgt 10 8345.300 ±
> 80.161 ns/op
> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ±
> 0.180 ns/op
> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ±
> 0.232 ns/op
Andrew Haley has updated the pull re
On Mon, 12 May 2025 09:48:03 GMT, Andrew Dinn wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Stub stack frame
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 2619:
>
On Mon, 12 May 2025 06:52:12 GMT, Per Minborg wrote:
> Looking at the improvements made, I suggest we also change (in
> `SegmentBulkOperations`):
>
> ```
> private static final int NATIVE_THRESHOLD_FILL = powerOfPropertyOr("fill",
> Architecture.isAARCH64() ? 18 : 5);
> ```
>
> to
>
> ```
>
nama false 262143 avgt 10 8345.300 ±
> 80.161 ns/op
> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ±
> 0.180 ns/op
> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ±
> 0.232 ns/op
Andrew Haley has updated the pull re
On Mon, 12 May 2025 09:18:13 GMT, Andrew Dinn wrote:
>> Andrew Haley has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> generate_unsafecopy_common_error_exit
>
> src/hotspot/cpu/aarch64/stubGenerator_aar
nama false 262143 avgt 10 8345.300 ±
> 80.161 ns/op
> MemorySegmentFillUnsafe.unsafe true 262143 avgt 10 2930.594 ±
> 0.180 ns/op
> MemorySegmentFillUnsafe.unsafe false 262143 avgt 10 3136.828 ±
> 0.232 ns/op
Andrew Haley has updated the pull re
On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley wrote:
> This intrinsic is generally faster than the current implementation for Panama
> segment operations for all writes larger than about 8 bytes in size,
> increasing to more than 2* the performance on larger memory blocks on
>
On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley wrote:
> This intrinsic is generally faster than the current implementation for Panama
> segment operations for all writes larger than about 8 bytes in size,
> increasing to more than 2* the performance on larger memory blocks on
>
On Fri, 9 May 2025 14:11:27 GMT, Andrew Haley wrote:
> This intrinsic is generally faster than the current implementation for Panama
> segment operations for all writes larger than about 8 bytes in size,
> increasing to more than 2* the performance on larger memory blocks on
>
This intrinsic is generally faster than the current implementation for Panama
segment operations for all writes larger than about 8 bytes in size, increasing
to more than 2* the performance on larger memory blocks on Graviton 2, between
"panama" (C2 generated, what we use now) and "unsafe" (this
On Thu, 8 May 2025 18:18:44 GMT, Chen Liang wrote:
> I noted that `ThreadFlock` is using scoped values but throwing
> `StructureViolationException` introduced by structured concurrency - is it
> considered an implementation artifact and part of structured concurrency
> instead?
>
> Context: t
> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a
> null argument.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Fix merge
-
Changes:
- a
On Wed, 30 Apr 2025 12:48:08 GMT, Alan Bateman wrote:
> @theRealAph Can you include the update to javax/security/auth/Subject.java as
> part of this?
Fixed now.
-
PR Comment: https://git.openjdk.org/jdk/pull/24923#issuecomment-2863756144
> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a
> null argument.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
ScopedValue::orElse() does not accept n
> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a
> null argument.
Andrew Haley has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains nine commits:
- Fix merge
- M
On Tue, 6 May 2025 21:45:34 GMT, Mohamed Issa wrote:
>> The goal of this PR is to implement an x86_64 intrinsic for
>> java.lang.Math.cbrt() using libm. There is a new set of micro-benchmarks are
>> included to check the performance of specific input value ranges to help
>> prevent regressions
> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a
> null argument.
Andrew Haley has updated the pull request incrementally with two additional
commits since the last revision:
- Remove unnecessary @since 25
- Remove un
On Thu, 1 May 2025 08:50:27 GMT, Hamlin Li wrote:
> > Overall, it still looks like a JDK build issue to me. Hiding problems
> > occurred during the build is not good. If some toolchains can't
> > successfully build the library, the library shouldn't be included in JDK.
>
> No, in riscv case (p
).
Again, this is an unhelpful thing to do. If the environment doesn't
support building the full JDK, kick it out.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a
> null argument.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Since when?
-
Changes:
- a
> Propose to finalize scoped values.
> The only functional change is that the orElse() method no longer accepts a
> null argument.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
ScopedValue::orElse() does not accept n
Propose to finalize scoped values.
The only functional change is that the orElse() method no longer accepts a null
argument.
-
Commit messages:
- 8355720: Implement JEP 506: Scoped Values
- Implement JEP 506: Scoped Values
Changes: https://git.openjdk.org/jdk/pull/24923/files
We
On Sun, 6 Apr 2025 03:48:22 GMT, Mohamed Issa wrote:
> the built in **cbrt** micro-benchmark
How should we run that benchmark? Thanks.
-
PR Comment: https://git.openjdk.org/jdk/pull/24470#issuecomment-2832035668
On Sun, 6 Apr 2025 03:48:22 GMT, Mohamed Issa wrote:
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.cbrt() using libm.
>
> The results of all tests posted below were captured with an [Intel® Xeon
> 6761P](https://www.intel.com/content/www/us/en/products/sku/2418
On Fri, 18 Apr 2025 01:36:10 GMT, erifan wrote:
>> This patch optimizes the following patterns:
>> For integer types:
>>
>> (XorV (VectorMaskCmp src1 src2 cond) (Replicate -1))
>> => (VectorMaskCmp src1 src2 ncond)
>> (XorVMask (VectorMaskCmp src1 src2 cond) (MaskAll m1))
>> => (VectorMa
On Sun, 20 Apr 2025 16:07:56 GMT, fabioromano1 wrote:
>> This PR implements nth root computation for `BigInteger`s using Newton
>> method and optimizes `BigInteger.pow(int)` method.
>> [Here is a proof of convergence of the recurrence
>> used.](https://github.com/user-attachments/files/19785045
On Sun, 20 Apr 2025 16:07:56 GMT, fabioromano1 wrote:
>> This PR implements nth root computation for `BigInteger`s using Newton
>> method and optimizes `BigInteger.pow(int)` method.
>> [Here is a proof of convergence of the recurrence
>> used.](https://github.com/user-attachments/files/19785045
On Sun, 20 Apr 2025 16:07:56 GMT, fabioromano1 wrote:
>> This PR implements nth root computation for `BigInteger`s using Newton
>> method and optimizes `BigInteger.pow(int)` method.
>> [Here is a proof of convergence of the recurrence
>> used.](https://github.com/user-attachments/files/19785045
On Mon, 3 Feb 2025 04:16:57 GMT, SendaoYan wrote:
>> Hi all,
>> Several JMH tests fails "Unrecognized VM option 'UseAVX=2'" on
>> linux-aarch64. The VM option '-XX:UseAVX=2' only support on x86_64 platform.
>> This PR add option '-XX:+IgnoreUnrecognizedVMOptions' to make test run
>> normally o
On Fri, 20 Dec 2024 15:42:14 GMT, Fei Gao wrote:
>> Galder Zamarreño has updated the pull request incrementally with five
>> additional commits since the last revision:
>>
>> - Added comment around the assertions
>> - Adjust min/max identity IR test expectations after changes
>> - Fix style
On Thu, 21 Nov 2024 17:21:07 GMT, Andrew Haley wrote:
> Test bug.
>
> Another bug caused by the result of `Math.abs()` being negative. I also tried
> `floorMod()`, which would have been cleaner, but it increased the runtime of
> this extremely time-sensitive benchmark.
This p
On Fri, 22 Nov 2024 10:36:21 GMT, Rémi Forax wrote:
> Let say that the definition of Math.abs() is surprising
If anything is surprising, it's the definition of `%` . Which is compatible
with `/`, but otherwise useless.
-
PR Comment: https://git.openjdk.org/jdk/pull/22297#issuecom
Test bug.
Another bug caused by the result of `Math.abs()` being negative. I also tried
`floorMod()`, which would have been cleaner, but it increased the runtime of
this extremely time-sensitive benchmark.
-
Commit messages:
- Fix integer overflow in abs()
Changes: https://git.op
On Tue, 22 Oct 2024 15:48:43 GMT, Andrew Haley wrote:
>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:
>>
>>> 58:
>>> 59: assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use
>>> fast_lock_lightweight");
&
On Tue, 22 Oct 2024 15:37:23 GMT, Andrew Haley wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code
On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo
wrote:
> * We copy the oops stored in the LockStack of the carrier to the
> stackChunk when freezing (and clear the LockStack). We copy the oops back to
> the LockStack of the next carrier when thawing for the first time (and clear
On Thu, 10 Oct 2024 16:16:51 GMT, Andrew Haley wrote:
> The fourth preview of scoped values.
This pull request has now been integrated.
Changeset: 3fab8e37
Author: Andrew Haley
URL:
https://git.openjdk.org/jdk/commit/3fab8e37bbebbb3930108b2015efe488b1fa1e97
Stats: 161 lines i
> The fourth preview of scoped values.
Andrew Haley 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 10 additional commits since the
last revis
> The fourth preview of scoped values.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Typo in comment. (Thanks, Roland!)
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21456/files
- new: https://git.openjdk.
> The fourth preview of scoped values.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
API change
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21456/files
- new: https://git.openjdk.org/jdk/pull/21456/fi
On Tue, 22 Oct 2024 15:37:23 GMT, Andrew Haley wrote:
>> Patricio Chilano Mateo has updated the pull request incrementally with six
>> additional commits since the last revision:
>>
>> - Fix comments in objectMonitor.hpp
>> - Move frame::saved_thread_address
On Tue, 22 Oct 2024 15:48:43 GMT, Andrew Haley wrote:
>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:
>>
>>> 58:
>>> 59: assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use
>>> fast_lock_lightweight");
&
On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo
wrote:
>> This is the implementation of JEP 491: Synchronize Virtual Threads without
>> Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for
>> further details.
>>
>> In order to make the code review easier the change
> The fourth preview of scoped values.
Andrew Haley 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 seven additional commits since
the last revis
On Mon, 14 Oct 2024 13:40:50 GMT, Andrew Haley wrote:
>> The fourth preview of scoped values.
>
> Andrew Haley has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Scoped values
> - Scoped values
Tier1 and Tie
> The fourth preview of scoped values.
Andrew Haley has updated the pull request incrementally with two additional
commits since the last revision:
- Scoped values
- Scoped values
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21456/files
- new: https://git.openjdk.
> The fourth preview of scoped values.
Andrew Haley has updated the pull request incrementally with one additional
commit since the last revision:
Fix javadoc
-
Changes:
- all: https://git.openjdk.org/jdk/pull/21456/files
- new: https://git.openjdk.org/jdk/pull/21456/fi
The fourth preview of scoped values.
-
Commit messages:
- Scoped Values API changes
- Scoped Values API changes
- Scoped Values API changes
Changes: https://git.openjdk.org/jdk/pull/21456/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21456&range=00
Issue: https://bugs
On Tue, 3 Sep 2024 15:50:13 GMT, Thomas Stuefe wrote:
>>> > I don't think the costs for two address comparisons matter, not with the
>>> > comparatively few deallocations that happen (few hundreds or few
>>> > thousand). If deallocate is hot, we are using metaspace wrong.
>>>
>>> MethodData do
On Wed, 9 Oct 2024 06:07:13 GMT, John R Rose wrote:
> If the interfaces had a compact numbering, and there were a side table
> mapping the compact numbers to interface Klass* pointers, then I think
> Andrew's code would still work (with natural adjustments).
Probably, yes. I can pack klass ID+
On Wed, 9 Oct 2024 09:00:06 GMT, Andrew Haley wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Replace Metaspace::is_compressed_klass_ptr with
>> CompressedKlassPointers::is_in_
yet making Klass
pointers a table index. Another chained load in the path of method
dispatch, at a time when I'm trying to get rid of chained loads, would
be a Bad Thing for me.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
-
PR Comment: https://git.openjdk.org/jdk/pull/19157#issuecomment-2401747594
mmit since the last revision:
>
> Replace Metaspace::is_compressed_klass_ptr with
> CompressedKlassPointers::is_in_encoding_range.
On 8 Oct 2024, at 4:07, Andrew Haley wrote:
> On 9/10/24 12:42, Coleen Phillimore wrote:
>> Thanks for reviewing Ioi and Thomas, and thank you Thomas for the
s a way to represent interface pointers in a compact way
in lookup tables, and to be able to get from compressed class pointers
to the address. As long as interface pointers are in a 32-bit range
and there's a fast way to get from compressed class to address that's
OK.
--
Andrew Haley (he/
On Fri, 27 Sep 2024 14:15:04 GMT, Galder Zamarreño wrote:
> The only situation where this PR is a regression compared to current code is
> when the one of the branch side is always taken.
Bear in mind that's quite common. It's not very unusual to clip a range with
something equivalent to `x =
On Tue, 27 Aug 2024 22:23:44 GMT, Srinivas Vamsi Parasa
wrote:
>> I agree, this is all rather obscure. Ideally the same names that are used in
>> wherever this comes from.
>>
>> Where does the algorithm come from? What are its accuracy guarantees?
>>
>> In addition, given the rarity of hyperb
On 8/27/24 12:13, Jatin Bhateja wrote:
Hi @vamsi-parasa , Kindly also add a JMH micro benchmark, I did a first
run and see around 4% performance drop with attached micro on Sapphire
Rapids.
[test.txt](https://github.com/user-attachments/files/16761142/test.txt)
If I had to guess, that's beca
On Tue, 27 Aug 2024 05:24:34 GMT, Jatin Bhateja wrote:
>> The goal of this PR is to implement an x86_64 intrinsic for
>> java.lang.Math.tanh() using libm
>>
>> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
>> -- | -- | -- | --
>> MathBench.tanhDouble | 70900 | 95618 | 1.35x
>
> src/
On Fri, 26 Jul 2024 18:39:27 GMT, Vladimir Ivanov wrote:
> Oh, it comes as a surprise to me... I was under impression that the first
> thing hand-coded assembly variants do is check for `bitmap !=
> SECONDARY_SUPERS_BITMAP_FULL`. At least, it was my recollection from working
> on [JDK-8180450]
On Thu, 25 Jul 2024 23:31:21 GMT, Vladimir Ivanov wrote:
> Thanks! The patch looks good, except there was one failure observed during
> testing with the latest patch [1]. It does look related to the latest changes
> you did in
> [54050a5](https://github.com/openjdk/jdk/pull/19989/commits/54050
this code is only used for generating stubs, and it seemed to me
> ridiculous to have stubs calling other stubs.
>
> I've followed the guidance from @iwanowww not to obsess too much about
> the performance of C1-compiled secondary supers lookups, and to prefer
> sim
On Thu, 25 Jul 2024 16:05:49 GMT, Andrew Haley wrote:
>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
this code is only used for generating stubs, and it seemed to me
> ridiculous to have stubs calling other stubs.
>
> I've followed the guidance from @iwanowww not to obsess too much about
> the performance of C1-compiled secondary supers lookups, and to prefer
> simplicity over abso
this code is only used for generating stubs, and it seemed to me
> ridiculous to have stubs calling other stubs.
>
> I've followed the guidance from @iwanowww not to obsess too much about
> the performance of C1-compiled secondary supers lookups, and to prefer
> simplicity over absol
On Wed, 24 Jul 2024 19:09:06 GMT, Vladimir Ivanov wrote:
>>> > Also also, Klass::is_subtype_of() is used for C1 runtime.
>>>
>>> Can you elaborate, please?
>>
>> Sorry, that was rather vague. In C1-compiled code, the Java method
>> `Class::isInstance(Object)`calls `Klass::is_subtype_of()`.
>>
1 - 100 of 252 matches
Mail list logo
