On Thu, 30 May 2024 06:21:36 GMT, Emanuel Peter wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove duplicate vm.compiler2.enabled
>
> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 29:
>
>> 27: * @re
On Wed, 29 May 2024 22:20:31 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Wed, 29 May 2024 22:20:31 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Tue, 21 May 2024 09:20:36 GMT, Adam Sotona wrote:
> j.l.classfile.ClassReader instance is exposed in the Class-File API through
> j.l.classfile.AttributeMapper::readAttribute method only.
> ClassReader only purpose is to serve as a tool for reading content of a
> custom attribute in a user-p
On Fri, 24 May 2024 21:39:33 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Fri, 24 May 2024 21:39:33 GMT, Brent Christian wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring
>> the spec in line with how the VM already behaves. The changes would focus on
>> _happens-before_ edges at some key points during reference processing.
>>
On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato wrote:
> There is an initialization code in `Console` class that searches for the
> Console implementations. Refactoring the init code not to use lambda/stream
> would reduce the (initial) number of loaded classes by about 100 for
> java.base implem
The message is generated if cores (or any other tools) section doesn't exist or
is empty. However, there is no any tool for cores processing now defined. So
ERROR message is generating, confusing users.
The fix is to don't print error for empty toolset which is the valid case. The
message is sti
On Wed, 29 May 2024 22:20:31 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
Hi Chen,
What is your usage pattern of these single-abstract-method implementations?
Since it sounds like you are
creating a lot of them, are you storing them in collections?
Yes, we do have such usage patterns, e.g. stores methods as Function in hash
table as handlers, etc.
If you are keepin
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has updated the pull r
On Wed, 29 May 2024 21:39:37 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/io/Console.java line 673:
>>
>>> 671: return new ProxyingConsole(jc);
>>> 672: }
>>> 673: break;
>>
>> Suggestion:
>>
On Wed, 29 May 2024 21:41:42 GMT, Vladimir Kozlov wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move assert to where it's actually important.
>
> test/jdk/TEST.ROOT line 103:
>
>> 101: vm.jvmti \
>> 102:
> Re-write the IndexOf code without the use of the pcmpestri instruction, only
> using AVX2 instructions. This change accelerates String.IndexOf on average
> 1.3x for AVX2. The benchmark numbers:
>
>
> BenchmarkScore
> Latest
On Tue, 28 May 2024 23:52:27 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Wed, 29 May 2024 21:27:30 GMT, Chen Liang wrote:
>> There is an initialization code in `Console` class that searches for the
>> Console implementations. Refactoring the init code not to use lambda/stream
>> would reduce the (initial) number of loaded classes by about 100 for
>> java.base im
On Tue, 28 May 2024 23:52:27 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato wrote:
> There is an initialization code in `Console` class that searches for the
> Console implementations. Refactoring the init code not to use lambda/stream
> would reduce the (initial) number of loaded classes by about 100 for
> java.base implem
On Wed, 29 May 2024 19:51:36 GMT, Naoto Sato wrote:
> There is an initialization code in `Console` class that searches for the
> Console implementations. Refactoring the init code not to use lambda/stream
> would reduce the (initial) number of loaded classes by about 100 for
> java.base implem
Hi Zhengyu,
What is your usage pattern of these single-abstract-method implementations?
Since it sounds like you are creating a lot of them, are you storing them
in collections?
If you are keeping a lot of them in collection (say, as event handlers),
you may try to use `MethodHandleProxies.asInterf
Hi Chen,
Thanks for the insights.
We did refactor our code to avoid using LambdaMetaFactory,metafactory()
directly.
With increasing use of Lambdas, in our applications and libraries, the
metaspace impact becomes a concern. If current implementation (not able to
unload unused Lambda classes) h
There is an initialization code in `Console` class that searches for the
Console implementations. Refactoring the init code not to use lambda/stream
would reduce the (initial) number of loaded classes by about 100 for java.base
implementations. This would become relevant when the java.io.IO (JEP
> I propose to add type-checked ConstantPool.entryByIndex and
> ClassReader.readEntryOrNull taking an extra Class parameter, which throws
> ConstantPoolException instead of ClassCastException on type mismatch, which
> can happen to malformed ClassFiles.
>
> Requesting a review from @asotona. Th
Hi Gu,
CallSite is specific to each invokedynamic instruction instead of each
InvokeDynamic constant pool entry:
https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-6.html#jvms-6.5.invokedynamic
And the linking is done by MethodHandleNatives.linkCallSite if you want to
follow the Java implemen
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has updated the pull r
On Wed, 29 May 2024 14:09:51 GMT, Viktor Klang wrote:
>> Doug Lea 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 41 additional commits
>> since
On Tue, 28 May 2024 23:52:27 GMT, Scott Gibbons wrote:
>> Re-write the IndexOf code without the use of the pcmpestri instruction, only
>> using AVX2 instructions. This change accelerates String.IndexOf on average
>> 1.3x for AVX2. The benchmark numbers:
>>
>>
>> Benchmark
Hello Lambda experts,
Since we upgraded JDK from 11 to 17, we’re experiencing metaspace pressure,
largely due to Lambda class implementation changes.
There’s a scenario (see attached test case), that is especially puzzled me,
hopefully, you can share some insights.
In this test case, there is
On Wed, 29 May 2024 15:50:05 GMT, Pavel Rappo wrote:
>> @cl4es, here are some results from my machine (macosx-aarch64):
>>
>> Name (size) Cnt BaseError TestError
>> Unit Change
>> ArraysHashCode.bytes1 150.715 ± 0.004 0.725 ± 0.029
On Wed, 29 May 2024 12:53:42 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 252:
>>
>>> 250: return switch (length) {
>>> 251: case 0 -> initialValue;
>>> 252: case 1 -> 31 * initialValue + (int) a[fromIndex];
>>
On Wed, 29 May 2024 12:44:45 GMT, Pavel Rappo wrote:
>> I don't care as long as microbenchmarks don't get a hiccup.
>
> @cl4es, here are some results from my machine (macosx-aarch64):
>
> Name (size) Cnt BaseError TestError
> Unit Change
> ArraysHashCode
> Please review this PR, which supersedes a now withdrawn
> https://github.com/openjdk/jdk/pull/14831.
>
> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
> user-friendly methods. Here's a summary:
>
> - Made the operand constants (i.e. `T_BOOLEAN` and friends) and the
>
On Thu, 16 May 2024 14:11:47 GMT, Maurizio Cimadamore
wrote:
> > > Do we have any performance tests available to see if there are any
> > > potential impacts?
> >
> >
> > I've run all micro benchmarks whose name match `LoopOver*`. No regression
> > was found. Few benchmarks seems a tad faste
> JEP 481 proposes Scoped Values to continue to preview in JDK 23 with one
> change. The type of the operation parameter of the callWhere method is
> changed to a new functional interface to avoid having the API throw
> Exception. With that change, the getWhere (and the corresponding method on
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has updated the pull r
On Wed, 29 May 2024 14:19:52 GMT, Viktor Klang wrote:
>> Doug Lea 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 41 additional commits
>> since
On Wed, 29 May 2024 13:26:10 GMT, Viktor Klang wrote:
>> Doug Lea 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 41 additional commits
>> since
On Wed, 29 May 2024 11:33:40 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments with
On Wed, 29 May 2024 11:33:40 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments with
On Tue, 28 May 2024 16:56:18 GMT, Naoto Sato wrote:
>> This test intends to verify the behavior of JdkConsole for the java.base
>> module, wrt restoring the echo. The test assumes the internal methods that
>> sets/gets the echo status of the platform.
>
> Naoto Sato has updated the pull request
On Wed, 29 May 2024 11:33:40 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments with
On Wed, 29 May 2024 11:33:40 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments with
On Wed, 29 May 2024 11:33:40 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments with
On Tue, 28 May 2024 22:31:15 GMT, Jonathan Gibbons wrote:
>> With the advent of JEP 467, `///` comments may be treated as documentation
>> comments, and may be subject to the recently new `javac` warning about
>> "dangling doc comments" in unexpected places.
>>
>> In keeping with the policy to
On Wed, 29 May 2024 11:33:40 GMT, Doug Lea wrote:
>> This set of changes address causes of poor utilization with small numbers of
>> cores due to overly aggressive contention avoidance. A number of further
>> adjustments were needed to still avoid most contention effects in
>> deployments with
On Wed, 29 May 2024 07:17:38 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>> regress
On Tue, 28 May 2024 19:13:50 GMT, Jorn Vernee wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 252:
>
On Tue, 28 May 2024 20:40:30 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 275:
>>
>>> 273: return switch (length) {
>>> 274: case 0 -> initialValue;
>>> 275: case 1 -> 31 * initialValue + (a[fromIndex] & 0xff)
On Wed, 29 May 2024 07:17:38 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>> regress
> I propose to add type-checked ConstantPool.entryByIndex and
> ClassReader.readEntryOrNull taking an extra Class parameter, which throws
> ConstantPoolException instead of ClassCastException on type mismatch, which
> can happen to malformed ClassFiles.
>
> Requesting a review from @asotona. Th
On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo wrote:
>> Please review this PR, which supersedes a now withdrawn
>> https://github.com/openjdk/jdk/pull/14831.
>>
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
>> user-friendly methods. Here's a summary:
>>
>> - Made t
On Wed, 29 May 2024 07:17:38 GMT, Adam Sotona wrote:
>> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
>> classfile API for reflection proxy-generation. Actual implementation of
>> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
>> regress
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has updated the pull r
> This set of changes address causes of poor utilization with small numbers of
> cores due to overly aggressive contention avoidance. A number of further
> adjustments were needed to still avoid most contention effects in deployments
> with large numbers of cores
Doug Lea has updated the pull r
On Wed, 15 May 2024 15:43:45 GMT, Maurizio Cimadamore
wrote:
> When creating a nested memory access var handle, we ensure that the segment
> is accessed at the correct alignment for the root layout being accessed. But
> we do not ensure that the segment has at least the size of the accessed ro
On Wed, 22 May 2024 21:03:57 GMT, Jorn Vernee wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typo in javadoc
>
> src/java.base/share/classes/java/lang/invoke/X-VarHandleSegmentView.java.template
> line
Hi,
When viewing the Javadoc of PrintStream, I noticed that the Javadocs of
the constructors involving charsets seems to be a bit lacking.
In most cases, these just mention something like "a charset" instead of
saying what it's used for. While the class description specifies that, I
think it c
On Wed, 29 May 2024 03:21:27 GMT, Chen Liang wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix incorrect utf16 hashCode adaptation
>
> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 320:
>
On Tue, 28 May 2024 20:21:34 GMT, Claes Redestad wrote:
>> test/hotspot/jtreg/compiler/intrinsics/TestArraysHashCode.java line 88:
>>
>>> 86: private static int testIntrinsic(byte[] bytes, int type)
>>> 87: throws InvocationTargetException, IllegalAccessException {
>>> 88:
On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo wrote:
>> Please review this PR, which supersedes a now withdrawn
>> https://github.com/openjdk/jdk/pull/14831.
>>
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
>> user-friendly methods. Here's a summary:
>>
>> - Made t
On Wed, 29 May 2024 03:16:02 GMT, Chen Liang wrote:
>> In fact, if I change it to `2`, the following tests will fail:
>>
>> - `jdk/jdk/classfile/Utf8EntryTest.java`
>> - `jdk/java/util/zip/ZipCoding.java`
>> - `jdk/java/text/Format/MessageFormat/MessageRegression.java`
>
> Indeed, the actu
> [JDK-8294961](https://bugs.openjdk.org/browse/JDK-8294961) changed to use
> classfile API for reflection proxy-generation. Actual implementation of
> `ProxyGenerator` is focused on performance, however it causes JDK bootstrap
> regressions. `ProxyGenerator.TEMPLATE` class model is statically c
62 matches
Mail list logo
