On Fri, 6 Jun 2025 06:00:48 GMT, Kim Barrett wrote:
>> Please review this change which adds a native method providing the
>> implementation of Reference::get. Referece::get is an intrinsic candidate,
>> so
>> this native method implementation is only used when the intrinsic is not.
>>
>> Curre
On Thu, 5 Jun 2025 08:42:38 GMT, Kim Barrett wrote:
>> Please review this change which adds a native method providing the
>> implementation of Reference::get. Referece::get is an intrinsic candidate,
>> so
>> this native method implementation is only used when the intrinsic is not.
>>
>> Curre
On Wed, 4 Jun 2025 07:12:42 GMT, Kim Barrett wrote:
>> Please review this change which adds a native method providing the
>> implementation of Reference::get. Referece::get is an intrinsic candidate,
>> so
>> this native method implementation is only used when the intrinsic is not.
>>
>> Curre
On Fri, 30 May 2025 11:25:01 GMT, Kim Barrett wrote:
> If get0() is the intrinsic, then I think that referenced snippet from the
Compile ctor can go away?
Yes.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/24315#discussion_r2116517383
On Thu, 29 May 2025 18:43:31 GMT, Vladimir Ivanov wrote:
>> We already have this to address that issue for the specific case of
>> Reference.get:
>> https://github.com/openjdk/jdk/blob/4cf729cfac57c9aec692a52c1f3f95f2403e7958/src/hotspot/share/opto/compile.cpp#L786-L792
>
On Thu, 29 May 2025 13:08:25 GMT, Kim Barrett wrote:
>> The current limitation of intrinsics support in C1/C2 is that intrinsics are
>> always applied in the context of some method (as part of inlining). If a
>> method is at the root of the compilation, it is never intrinsified.
>>
>> The prob
On Sat, 24 May 2025 04:57:39 GMT, Kim Barrett wrote:
>> As I understand, `JDK-8271862` was about migrating to non-virtual intrinsic
>> method.
>> In case of `Reference::get()`, you already have a virtual public method
>> marked as `@IntrinsicCandidate`. And the patch doesn't change anything
>>
On Tue, 20 May 2025 22:14:42 GMT, Kim Barrett wrote:
>> src/java.base/share/classes/java/lang/ref/Reference.java line 366:
>>
>>> 364:
>>> 365: /* Implementation of unintrinsified get(). Making get() native
>>> may lead
>>> 366: * C2 to sometimes prefer the native implementation over
On Fri, 9 May 2025 15:59:38 GMT, Kim Barrett wrote:
>> Please review this change which adds a native method providing the
>> implementation of Reference::get. Referece::get is an intrinsic candidate,
>> so
>> this native method implementation is only used when the intrinsic is not.
>>
>> Curre
On Mon, 5 May 2025 23:50:31 GMT, Ioi Lam wrote:
>> This is a general fix for all the "points to a static field that may hold a
>> different value" failures related to `java/lang/invoke/MethodHandleImpl`.
>> E.g., [JDK-8354840](https://bugs.openjdk.org/browse/JDK-8354840),
>> [JDK-8353330](http
On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
>
> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a
> released jdk not supportting sleef (for any reason, e.g. low gcc version,
> intrinsic not supported, rvv not supported,
On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
>
> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a
> released jdk not supportting sleef (for any reason, e.g. low gcc version,
> intrinsic not supported, rvv not supported,
On Wed, 30 Apr 2025 11:00:04 GMT, Hamlin Li wrote:
> It's arguable if missing entries is a bug, please check
> [JDK-8355656](https://bugs.openjdk.org/browse/JDK-8355656) for example
Personally, I'm surprised SVML is affected in a similar way because stubs are
provided in assembly form, so they
On Tue, 29 Apr 2025 09:16:39 GMT, Hamlin Li wrote:
> This behavour was decided in previous PRs
> https://github.com/openjdk/jdk/pull/20781,
> https://github.com/openjdk/jdk/pull/21083,
> https://github.com/openjdk/jdk/pull/21502, and some other uncommited PRs
> prior to these ones.
Can you p
On Mon, 28 Apr 2025 10:34:49 GMT, Hamlin Li wrote:
> Hi,
> Can you help to review this patch?
>
> Before [JDK-8353786](https://bugs.openjdk.org/browse/JDK-8353786), when a
> released jdk not supportting sleef (for any reason, e.g. low gcc version,
> intrinsic not supported, rvv not supported,
On Mon, 28 Apr 2025 19:41:28 GMT, Vladimir Ivanov wrote:
> Both SVML and SLEEF libraries reuse 128-bit versions for vector of 2 floats.
> Usually, only `Float64Vector` shape satisfies that condiditon, but
> with`-XX:MaxVectorSize=8` `FloatMaxVector` becomes 2 element vecto
On Mon, 28 Apr 2025 19:41:28 GMT, Vladimir Ivanov wrote:
> Both SVML and SLEEF libraries reuse 128-bit versions for vector of 2 floats.
> Usually, only `Float64Vector` shape satisfies that condiditon, but
> with`-XX:MaxVectorSize=8` `FloatMaxVector` becomes 2 element vecto
Both SVML and SLEEF libraries reuse 128-bit versions for vector of 2 floats.
Usually, only `Float64Vector` shape satisfies that condiditon, but
with`-XX:MaxVectorSize=8` `FloatMaxVector` becomes 2 element vector as well.
Adjust the relevant logic to match vector of 2 floats shape structurally.
On Fri, 25 Apr 2025 09:41:21 GMT, Jatin Bhateja wrote:
>> It does look attractive, but macro expansion-based solution requires JVM to
>> internalize such operations and their properties.
>>
>> IMO a higher-level solution based on more generic JVM primitives would
>> enable libraries to proper
On Fri, 25 Apr 2025 05:26:35 GMT, Vladimir Ivanov wrote:
>> Migrate Vector API math library (SVML and SLEEF) linkage from native code
>> (in JVM) to Java FFM API.
>>
>> Since FFM API doesn't support vector calling conventions yet, migration
>> affects only
On Fri, 4 Apr 2025 22:52:24 GMT, Vladimir Ivanov wrote:
> Migrate Vector API math library (SVML and SLEEF) linkage from native code (in
> JVM) to Java FFM API.
>
> Since FFM API doesn't support vector calling conventions yet, migration
> affects only symbol lookup f
On Fri, 25 Apr 2025 00:06:28 GMT, Fei Yang wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve comments
>
> src/hotspot/cpu/riscv/riscv.ad line 1947:
>
>> 194
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
Remove UseVectorStubs
On Thu, 24 Apr 2025 11:33:43 GMT, Hamlin Li wrote:
>> FTR both `VectorSupport.getMaxLaneCount()` and `CPUFeatures` don't rely on
>> raw list of ISA extensions CPU supports, but only those reported by the JVM.
>> So, if some feature support is disabled on JVM side, it won't be reported by
>> `
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
Improve commen
On Thu, 24 Apr 2025 18:57:11 GMT, Jatin Bhateja wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> CPUFeatures: RISC-V support
>
> src/hotspot/share/opto/vectorIntrinsics.cpp line
On Wed, 23 Apr 2025 18:11:42 GMT, Vladimir Ivanov wrote:
>> In previous code, we use `UseRVV` to detect if rvv extension is supported.
>>
>> On the other hand, user can choose to disable UseRVV if they want even if
>> rvv extension is supported on the running machi
On Wed, 23 Apr 2025 08:54:23 GMT, Hamlin Li wrote:
>> The intention is to align `_features_string` with `_features` which
>> enumerates well-known CPU capabilities JVM manages. As of now,
>> `_features_string` contains more information, so I introduced
>> `_cpu_info_string` to keep it.
>>
>>
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
CPUFeatures: RISC-V suppo
On Wed, 23 Apr 2025 08:43:47 GMT, Hamlin Li wrote:
>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathLibrary.java
>> line 288:
>>
>>> 286: IntFunction>
>>> implSupplier,
>>> 287: V v) {
>>> 288: var entry = lookup(op, opc, vspe
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
Avoid thread state tran
On Fri, 18 Apr 2025 16:16:28 GMT, Jorn Vernee wrote:
>> Vladimir Ivanov 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 Tue, 22 Apr 2025 14:46:21 GMT, Ludovic Henry wrote:
>> Vladimir Ivanov 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 Tue, 22 Apr 2025 16:46:44 GMT, Hamlin Li wrote:
>> src/hotspot/share/runtime/abstract_vm_version.cpp line 349:
>>
>>> 347: assert(features_offset <= cpu_info_string_len, "");
>>> 348: if (features_offset < cpu_info_string_len) {
>>> 349: assert(cpu_info_string[features_offset + 0] ==
On Tue, 22 Apr 2025 13:45:26 GMT, Hamlin Li wrote:
>> Vladimir Ivanov 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 24 addi
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
riscv fix
-
On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg wrote:
> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and
> `j.l.String.hashIsZero`. This means the VM can trust these fields to never
> change which enables constant folding optimizations.
>
> This PR is tested in tier1, t
On Thu, 17 Apr 2025 01:36:39 GMT, Xiaohong Gong wrote:
>> How does it work now? The code in `generate_vector_math_stubs()` in
>> `stubGenerator_aarch64.cpp` only populates `VEC_SIZE_SCALABLE` shapes with
>> SVE versions.
>
> Please see the `addr` definition code in
> https://github.com/openjdk
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the un
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
RVV and SVE adjustmen
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
fix broken mer
On Wed, 16 Apr 2025 19:29:07 GMT, Vladimir Ivanov wrote:
>> Migrate Vector API math library (SVML and SLEEF) linkage from native code
>> (in JVM) to Java FFM API.
>>
>> Since FFM API doesn't support vector calling conventions yet, migration
>> affects only
On Wed, 16 Apr 2025 02:11:09 GMT, Xiaohong Gong wrote:
>> Vladimir Ivanov 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
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 21 commi
On Wed, 16 Apr 2025 00:25:59 GMT, Paul Sandoz wrote:
>> Vladimir Ivanov 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, 16 Apr 2025 01:47:02 GMT, Xiaohong Gong wrote:
>> src/hotspot/share/opto/vectorIntrinsics.cpp line 488:
>>
>>> 486: // V binaryOp(long address, Class vClass, Class
>>> elementType, int length,
>>> 487: //V v1, V v2,
>>> 488: //BinaryOperation defaultImpl)
>>
>>
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
Fix debugName handli
On Tue, 15 Apr 2025 09:29:32 GMT, Xiaohong Gong wrote:
>> Vladimir Ivanov 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
139.7067 | 4118.763 | 8352.657 | 12491.14 | 16085.63 | 18101.67 |
> 21001.52 | 23847.33 | 26481.25 | 28273.93
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
8346230: [perf] scalability issue for the specjvm2008::xml.transform
On Fri, 17 Jan 2025 23:08:20 GMT, Vladimir Ivanov wrote:
> The HashMap for caching was deleted. Now it use only ThreadLocal variable
> without synchronization.
> According to the specjvm2008::xml.transform workload the performance for low
> threads counts was not affected and impro
On Fri, 11 Apr 2025 10:13:41 GMT, Jatin Bhateja wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8346230: [perf] scalability issue for the specjvm2008::xml.transform
>> workload
On Mon, 14 Apr 2025 15:22:21 GMT, Vladimir Ivanov wrote:
>> The HashMap for caching was deleted. Now it use only ThreadLocal variable
>> without synchronization.
>> According to the specjvm2008::xml.transform workload the performance for low
>> threads counts was not a
On Fri, 11 Apr 2025 10:06:06 GMT, Jatin Bhateja wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8346230: [perf] scalability issue for the specjvm2008::xml.transform
>> workload
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the un
On Mon, 7 Apr 2025 06:44:16 GMT, Per Minborg wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> features_string -> cpu_info_string
>
> src/jdk.incubator.vector/s
On Mon, 7 Apr 2025 17:01:19 GMT, Vladimir Kozlov wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> features_string -> cpu_info_string
>
> src/jdk.incubator.vector/s
On Mon, 7 Apr 2025 17:44:33 GMT, Chen Liang wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> features_string -> cpu_info_string
>
> src/jdk.incubator.vector/share/classes/jdk/
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
Fix windows-aarch64 buil
On Mon, 7 Apr 2025 23:03:03 GMT, Vladimir Ivanov wrote:
>> Migrate Vector API math library (SVML and SLEEF) linkage from native code
>> (in JVM) to Java FFM API.
>>
>> Since FFM API doesn't support vector calling conventions yet, migration
>> affects only
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
features_string -> cpu
crobenchmarks on linux-x64 and macosx-aarch64).
>
> Testing: hs-tier1 - hs-tier6, microbenchmarks (on linux-x64 and
> macosx-aarch64)
>
> Thanks!
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
Reviews and Float64V
Migrate Vector API math library (SVML and SLEEF) linkage from native code (in
JVM) to Java FFM API.
Since FFM API doesn't support vector calling conventions yet, migration affects
only symbol lookup for now. But it still enables significant simplifications on
JVM side.
The patch consists of th
On Thu, 6 Mar 2025 03:35:20 GMT, SendaoYan wrote:
> Hi all,
>
> The return type of function `const __m256i &perm` is `__m256i`, so `const
> __m256i &perm` should be replaced as 'const __m256i perm'.
>
> The function implementation in gcc/clang compiler header:
>
> 1. gcc: lib/gcc/x86_64-pc-li
On Thu, 6 Mar 2025 03:35:20 GMT, SendaoYan wrote:
> Hi all,
>
> The return type of function `const __m256i &perm` is `__m256i`, so `const
> __m256i &perm` should be replaced as 'const __m256i perm'.
>
> The function implementation in gcc/clang compiler header:
>
> 1. gcc: lib/gcc/x86_64-pc-li
139.7067 | 4118.763 | 8352.657 | 12491.14 | 16085.63 | 18101.67 |
> 21001.52 | 23847.33 | 26481.25 | 28273.93
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
8346230: [perf] scalability issue for the specjvm2008::xml.transform
On Fri, 14 Mar 2025 01:28:34 GMT, Vladimir Ivanov wrote:
>> The HashMap for caching was deleted. Now it use only ThreadLocal variable
>> without synchronization.
>> According to the specjvm2008::xml.transform workload the performance for low
>> threads counts was not a
On Wed, 12 Mar 2025 15:53:33 GMT, Vladimir Ivanov wrote:
> Tests that use data from the file 'cmudict-0.7b.txt' was deleted. Currently
> these tests using empty data set that looks bad.
This pull request has now been integrated.
Changeset: 50ac24eb
Author: Vladimir Ivanov
On Mon, 24 Mar 2025 19:34:55 GMT, Vladimir Ivanov wrote:
>> Tests that use data from the file 'cmudict-0.7b.txt' was deleted. Currently
>> these tests using empty data set that looks bad.
>
> Vladimir Ivanov has updated the pull request incrementally with one
> a
On Thu, 20 Mar 2025 23:39:24 GMT, Vladimir Ivanov wrote:
>> Tests that use data from the file 'cmudict-0.7b.txt' was deleted. Currently
>> these tests using empty data set that looks bad.
>
> Vladimir Ivanov has updated the pull request incrementally with one
> a
> Tests that use data from the file 'cmudict-0.7b.txt' was deleted. Currently
> these tests using empty data set that looks bad.
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
8351593: [JMH] test PhoneCode.
On Thu, 20 Mar 2025 23:39:24 GMT, Vladimir Ivanov wrote:
>> Tests that use data from the file 'cmudict-0.7b.txt' was deleted. Currently
>> these tests using empty data set that looks bad.
>
> Vladimir Ivanov has updated the pull request incrementally with one
> a
> the test output was cleanup for common execution.
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
8351593: [JMH] test PhoneCode.Bulk reports NPE exception
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24
On Wed, 12 Mar 2025 15:53:33 GMT, Vladimir Ivanov wrote:
> the test output was cleanup for common execution.
Is it make sense to restore the 'cmudict-0.7b.txt' from the old
'https://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks'?
-
PR Comment: http
2vCPU - 12743.4, 224vCPU - 13481.31 ops/m
> patched: 1vCPU - 149.77, 112vCPU - 13122.82, 224vCPU - 14751.57 ops/m
>
> According to the JFR the locking time for XMLReader object reduced from
> ~27sec to ~20sec for 224vCPU run.
Vladimir Ivanov has updated the pull request incrementally
2vCPU - 12743.4, 224vCPU - 13481.31 ops/m
> patched: 1vCPU - 149.77, 112vCPU - 13122.82, 224vCPU - 14751.57 ops/m
>
> According to the JFR the locking time for XMLReader object reduced from
> ~27sec to ~20sec for 224vCPU run.
Vladimir Ivanov has updated the pull request incrementally
the test output was cleanup for common execution.
-
Commit messages:
- JDK-8351593 [JMH] test PhoneCode.Bulk reports NPE exception
Changes: https://git.openjdk.org/jdk/pull/24011/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24011&range=00
Issue: https://bugs.openjdk.or
On Fri, 28 Feb 2025 01:20:44 GMT, Vladimir Ivanov wrote:
> The scope was updated to support multithread configuration (jmh option '-t
> 2') . No other changes needed.
This pull request has now been integrated.
Changeset: 4e67ac41
Author: Vladimir Ivanov
Committer:
On Mon, 3 Mar 2025 20:24:54 GMT, Vladimir Ivanov wrote:
> test setup was updated to generate data of requested size.
This pull request has now been integrated.
Changeset: 7c22b814
Author: Vladimir Ivanov
URL:
https://git.openjdk.org/jdk/com
On Fri, 7 Mar 2025 15:51:36 GMT, Vladimir Ivanov wrote:
>> test setup was updated to generate data of requested size.
>
> Vladimir Ivanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> JDK-8350811 [JMH] test foreign.S
> test setup was updated to generate data of requested size.
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8350811 [JMH] test foreign.StrLenTest failed with
StringIndexOutOfBoundsException for size=
On Fri, 7 Mar 2025 05:59:29 GMT, Jatin Bhateja wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8350811 [JMH] test foreign.StrLenTest failed with
>> StringIndexOutOfBoundsE
On Fri, 7 Mar 2025 05:47:59 GMT, Jatin Bhateja wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8350811 [JMH] test foreign.StrLenTest failed with
>> StringIndexOutOfBoundsE
> test setup was updated to generate data of requested size.
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8350811 [JMH] test foreign.StrLenTest failed with
StringIndexOutOfBoundsException for size=
On Fri, 28 Feb 2025 01:20:44 GMT, Vladimir Ivanov wrote:
> The scope was updated to support multithread configuration (jmh option '-t
> 2') . No other changes needed.
Thanks for your review!
-
PR Comment: https://git.openjdk.org/jdk/pull/23834#issuecomment-2704538159
On Tue, 4 Mar 2025 19:37:32 GMT, Vladimir Ivanov wrote:
>> test setup was updated to generate data of requested size.
>
> Vladimir Ivanov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> JDK-8350811 [JMH] test foreign.S
On Wed, 5 Mar 2025 23:29:42 GMT, Volodymyr Paprotski
wrote:
>> Vladimir Ivanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8350811 [JMH] test foreign.StrLenTest failed with
>> StringIndexOut
On Mon, 3 Mar 2025 20:24:54 GMT, Vladimir Ivanov wrote:
> test setup was updated to generate data of requested size.
Update to regular cycle template. Thanks
-
PR Comment: https://git.openjdk.org/jdk/pull/23873#issuecomment-2698720228
> test setup was updated to generate data of requested size.
Vladimir Ivanov has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8350811 [JMH] test foreign.StrLenTest failed with
StringIndexOutOfBoundsException for size=
On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov wrote:
> Array initialization by parameter was added. Extra constant was used to align
> cycle step with used arrays.
This pull request has now been integrated.
Changeset: 768b0241
Author:Vladimir Ivanov
Committer: Derek Whit
On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov wrote:
> Array initialization by parameter was added. Extra constant was used to align
> cycle step with used arrays.
Thanks for your review!
-
PR Comment: https://git.openjdk.org/jdk/pull/23783#issuecomment-2695524548
test setup was updated to generate data of requested size.
-
Commit messages:
- JDK-8350811 [JMH] test foreign.StrLenTest failed with
StringIndexOutOfBoundsException for size=451
Changes: https://git.openjdk.org/jdk/pull/23873/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&p
On Sat, 1 Mar 2025 00:40:26 GMT, Sandhya Viswanathan
wrote:
>> Array initialization by parameter was added. Extra constant was used to
>> align cycle step with used arrays.
>
> test/micro/org/openjdk/bench/jdk/incubator/vector/IndexInRangeBenchmark.java
> line 51:
>
>> 49: @Setup(Level.Tr
The scope was updated to support multithread configuration (jmh option '-t 2')
. No other changes needed.
-
Commit messages:
- JDK-8350909 [JMH] test ThreadOnSpinWaitShared failed for 2 threads config
Changes: https://git.openjdk.org/jdk/pull/23834/files
Webrev: https://webrevs.o
On Tue, 25 Feb 2025 21:35:22 GMT, Vladimir Ivanov wrote:
> The 'size' parameters was used instead of hardcoded constant to improve
> support for different sizes.
This pull request has now been integrated.
Changeset: f1398ecb
Author: Vladimir Ivanov
Committer:
On Tue, 25 Feb 2025 21:35:22 GMT, Vladimir Ivanov wrote:
> The 'size' parameters was used instead of hardcoded constant to improve
> support for different sizes.
Thanks for your review!
-
PR Comment: https://git.openjdk.org/jdk/pull/23785#issuecomment-2688965214
On Tue, 25 Feb 2025 19:06:05 GMT, Vladimir Ivanov wrote:
> Array initialization by parameter was added. Extra constant was used to align
> cycle step with used arrays.
Yes, exceptions reported for runs with size=1024. The test support max size=512
and have no checks for passed
The 'size' parameters was used instead of hardcoded constant to improve support
for different sizes.
-
Commit messages:
- JDK-8350701 [JMH] test foreign.AllocFromSliceTest failed with Exception for
size>1024
Changes: https://git.openjdk.org/jdk/pull/23785/files
Webrev: https://w
Array initialization by parameter was added. Extra constant was used to align
cycle step with used arrays.
-
Commit messages:
- 8350682 [JMH] vector.IndexInRangeBenchmark failed with
IndexOutOfBoundsException for size=1024
Changes: https://git.openjdk.org/jdk/pull/23783/files
We
On Thu, 20 Feb 2025 20:19:15 GMT, Coleen Phillimore wrote:
>> Class.isInterface() can check modifier flags, Class.isArray() can check
>> whether component mirror is non-null and Class.isPrimitive() needs a new
>> final transient boolean in java.lang.Class that the JVM code initializes.
>> Teste
On Fri, 7 Feb 2025 19:13:07 GMT, Coleen Phillimore wrote:
> I think the intrinsic for isInterface can be removed
Good point. Moreover, it seems most of intrinsics on Class queries can be
replaced with a flag bit check on the mirror. (Do we have 16 unused bits in
Class::modifiers after this cha
1 - 100 of 223 matches
Mail list logo
