> This patch adds `javap -verify` option to check the class and print obvious
> verification errors found.
> Implementation depends on extended Class-File API verification support, so PR
> #16809 is important to precede.
> The new `javap` option is mentioned in man pages and a release note will b
On Fri, 24 Nov 2023 13:20:20 GMT, Adam Sotona wrote:
> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
> bytecode-level class verification.
> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
> additional class checks inspired by
> `hotspot/share
On Thu, 30 May 2024 20:10:05 GMT, Alexey Semenyuk wrote:
> - Get rid of DottedVersion#greedy field.
> - Add support to save the unrecognizable remainder of the version string
> (required to handle Wix4 version string).
> - Implement DottedVersion#equals().
> - add DottedVersion#compareCompone
On Thu, 30 May 2024 22:54:12 GMT, Alexander Matveev
wrote:
>> This issue is reproducible with and without `--mac-sign`. jpackage will
>> "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by
>> using pseudo-identity "_-_". This is why jpackage tries to sign added files
>> a
On Thu, 30 May 2024 20:26:02 GMT, Alexey Semenyuk wrote:
> Change jpackage tests output from:
>
>
> [19:16:29.586] Create: SimplePackageTest.test
> [19:16:29.587] [ RUN ] SimplePackageTest.test
> [19:16:29.663] TRACE: Bundler rpm supported
> [19:16:29.674] TRACE: Actions: [[initialize], [create
On Fri, 31 May 2024 01:34:45 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.
>>
> 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.
>
> A couple key things we want to be able to say are:
> - `Refer
On Thu, 30 May 2024 05:14:30 GMT, Joe Darcy wrote:
>> Brent Christian has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 69 commits:
>>
>> - Merge branch 'master' into refDocs2
>> - add link to Thread.isAlive()
>> - small review t
Now that you mentioned it was added in Java 23, I went back to check
what change brought that in. Turns out it was me who introduced it, that
too as recently as a few months back. I too had forgotten about it :)
-Jaikiran
On 31/05/24 6:40 am, Lance Andersen wrote:
I was looking at jdk 22 and
I was looking at jdk 22 and now see the npe was added to the constructor
specification earlier this year and I reviewed it🙈
Sent from my iPad
> On May 30, 2024, at 8:56 PM, Jaikiran Pai wrote:
>
> On Thu, 30 May 2024 14:56:00 GMT, Lance Andersen wrote:
>
>>> Jaikiran Pai has updated the pull
Can I please get a review of this test-only change which updates a couple of
places in the test to use `try-with-resource`?
As noted in https://bugs.openjdk.org/browse/JDK-7022325 this change should
prevent leaking of resources in case there's any failure in the test. The test
continues to pass
On Thu, 30 May 2024 14:56:00 GMT, Lance Andersen wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> introduce a basic test for GZIPInputStream
>
> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 97
On Fri, 24 May 2024 16:17:41 GMT, Adam Sotona wrote:
>> ClassFile API `jdk.internal.classfile.verifier.VerifierImpl` performed only
>> bytecode-level class verification.
>> This patch adds `jdk.internal.classfile.verifier.ParserVerifier` with
>> additional class checks inspired by
>> `hotspot/
On Thu, 30 May 2024 20:10:05 GMT, Alexey Semenyuk wrote:
> - Get rid of DottedVersion#greedy field.
> - Add support to save the unrecognizable remainder of the version string
> (required to handle Wix4 version string).
> - Implement DottedVersion#equals().
> - add DottedVersion#compareCompone
> 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 Thu, 30 May 2024 17:04:44 GMT, Jorn Vernee wrote:
> I suggest leaving a comment to document which cases this cache is trying to
> address. I think that's mainly cases where the same ValueLayout is created
> many times in different places (instead of the same layout being reused, for
> which
On Thu, 30 May 2024 20:26:02 GMT, Alexey Semenyuk wrote:
> Change jpackage tests output from:
>
>
> [19:16:29.586] Create: SimplePackageTest.test
> [19:16:29.587] [ RUN ] SimplePackageTest.test
> [19:16:29.663] TRACE: Bundler rpm supported
> [19:16:29.674] TRACE: Actions: [[initialize], [create
On Thu, 30 May 2024 22:54:12 GMT, Alexander Matveev
wrote:
>> This issue is reproducible with and without `--mac-sign`. jpackage will
>> "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by
>> using pseudo-identity "_-_". This is why jpackage tries to sign added files
>> a
> This issue is reproducible with and without `--mac-sign`. jpackage will
> "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by
> using pseudo-identity "_-_". This is why jpackage tries to sign added files
> and this is expected behavior by jpackage. "codesign" fails since a
On Thu, 30 May 2024 20:26:02 GMT, Alexey Semenyuk wrote:
> Change jpackage tests output from:
>
>
> [19:16:29.586] Create: SimplePackageTest.test
> [19:16:29.587] [ RUN ] SimplePackageTest.test
> [19:16:29.663] TRACE: Bundler rpm supported
> [19:16:29.674] TRACE: Actions: [[initialize], [create
On Thu, 30 May 2024 20:26:02 GMT, Alexey Semenyuk wrote:
> Change jpackage tests output from:
>
>
> [19:16:29.586] Create: SimplePackageTest.test
> [19:16:29.587] [ RUN ] SimplePackageTest.test
> [19:16:29.663] TRACE: Bundler rpm supported
> [19:16:29.674] TRACE: Actions: [[initialize], [create
> 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.
>
> A couple key things we want to be able to say are:
> - `Refer
On Thu, 30 May 2024 19:44:29 GMT, David M. Lloyd wrote:
>> Chen Liang 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 s
> Get JDK 24 underway.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Temporarily problem list java.lang.instrument tests until jar generation is
fixed.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18787/files
-
Change jpackage tests output from:
[19:16:29.586] Create: SimplePackageTest.test
[19:16:29.587] [ RUN ] SimplePackageTest.test
[19:16:29.663] TRACE: Bundler rpm supported
[19:16:29.674] TRACE: Actions: [[initialize], [create], [unpack],
[verify-install], [finalize]]
to:
[19:16:29.586] Create
On Thu, 4 Apr 2024 16:57:40 GMT, Liam Miller-Cushon wrote:
>> This change fixes a zip64 bug in the launcher that is prevent it from
>> reading the manifest of jars where the 'relative offset of local header'
>> field in the central directory entry is >4GB. As described in APPNOTE.TXT
>> 4.5.3,
- Get rid of DottedVersion#greedy field.
- Add support to save the unrecognizable remainder of the version string
(required to handle Wix4 version string).
- Implement DottedVersion#equals().
- add DottedVersion#compareComponents(DottedVersion, DottedVersion) that
compares recognized component
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 Thu, 30 May 2024 20:10:05 GMT, Alexey Semenyuk wrote:
> - Get rid of DottedVersion#greedy field.
> - Add support to save the unrecognizable remainder of the version string
> (required to handle Wix4 version string).
> - Implement DottedVersion#equals().
> - add DottedVersion#compareCompone
On Fri, 3 May 2024 08:47:03 GMT, Justin Lu wrote:
> Please review this PR which corrects an edge case bug for
> java.text.DecimalFormat that causes incorrect parsing results for strings
> with very large exponent values.
>
> When parsing values with large exponents, if the value of the exponen
On Fri, 17 May 2024 21:59:38 GMT, Justin Lu wrote:
>> Please review this PR which corrects an edge case bug for
>> java.text.DecimalFormat that causes incorrect parsing results for strings
>> with very large exponent values.
>>
>> When parsing values with large exponents, if the value of the e
> 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
On Wed, 29 May 2024 19:27:17 GMT, Chen Liang wrote:
>> 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 malfor
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 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 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 Wed, 22 May 2024 14:33:31 GMT, Aleksey Shipilev wrote:
>> Why can't you do something like this:
>>
>> return cloneArray ? ReflectionFactory.copyClasses(interfaces) : interfaces;
>>
>>
>> Alternatively, your proposal is a good one too; we can rename this
>> `getInterfaces(boolean)` to `getI
On Wed, 22 May 2024 09:39:50 GMT, Aleksey Shipilev 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
>> parame
On Wed, 22 May 2024 13:44:59 GMT, Chen Liang wrote:
>> @liach I see such an opportunity in `Proxy.getProxyConstructor`, is that
>> what you have in mind?
>
> No, I mean here:
> https://github.com/openjdk/jdk/blob/4f1a10f84bcfadef263a0890b6834ccd3d5bb52f/src/java.base/share/classes/java/lang/Cla
On Wed, 22 May 2024 12:58:40 GMT, jengebr wrote:
>> Can't this be used by class cloning interfaces too?
>
> @liach I see such an opportunity in `Proxy.getProxyConstructor`, is that what
> you have in mind?
No, I mean here:
https://github.com/openjdk/jdk/blob/4f1a10f84bcfadef263a0890b6834ccd3d5
On Thu, 23 May 2024 09:05:09 GMT, Aleksey Shipilev wrote:
>> Alternatively, if a utility method is overkill, we can inline these to
>> `Executable`:
>>
>> public Class[] getParameterTypes() {
>> var shared = getSharedParameterTypes();
>> return shared.length == 0 ? shared : shared.clone
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:24:40 GMT, jengebr wrote:
>> No, I mean here:
>> https://github.com/openjdk/jdk/blob/4f1a10f84bcfadef263a0890b6834ccd3d5bb52f/src/java.base/share/classes/java/lang/Class.java#L1329
>>
>> (That's also why I suggest putting the utiltiy method in ReflectionFactory
>> instea
On Wed, 22 May 2024 10:27:16 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line
>> 249:
>>
>>> 247: * the original can safely be reused.
>>> 248: */
>>> 249: public Class[] copyClasses(Class[] classes) {
>>
>> There is no need t
On Fri, 24 May 2024 21:59:58 GMT, Chen Liang wrote:
> Can you update the ending copyright years from 2023 to 2024 on the 2nd line
> of the 2 modified files?
Done, thank you.
-
PR Comment: https://git.openjdk.org/jdk/pull/19327#issuecomment-2135215681
On Wed, 22 May 2024 09:44:18 GMT, Aleksey Shipilev wrote:
> Please also enable GHA testing: https://github.com/jengebr/jdk/actions. You
> may need to trigger the test run manually after this, since the PR hook have
> already missed it. Go to "OpenJDK Sanity Checks" on the left on that page,
>
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 Tue, 21 May 2024 14:07:29 GMT, jengebr wrote:
> Any suggestions?
I would recommend a new method `copyClasses`/`copyTypes` in
`jdk.internal.reflect.ReflectionFactory`, as it already has related
`copyConstructor` and `getExecutableSharedParameterTypes` methods.
Also, can you rename your PR's
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
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
returning the original `Class[0]` is sufficient.
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
The original way of building static libraries in the JDK was to use the
configure argument --enable-static-build, which set the value of the make
variable STATIC_BUILD. (Note that this is not the same as the source code
definition STATIC_BUILD, which will be set by other means as well.)
This me
> 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 Thu, 30 May 2024 18:39:19 GMT, Chen Liang wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update symbol files for JDK 23 build 25.
>
> src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-N.sym.txt line 1:
>
On Thu, 30 May 2024 18:38:59 GMT, Pavel Rappo wrote:
>> In fact, this started simply for incorporating JLine implementation into
>> Console, and using ServiceLoader was a mere means to load its impl as it
>> resides outside the java.base module. So yes, module and its console
>> implementation
On Thu, 30 May 2024 18:10:14 GMT, Naoto Sato wrote:
>> Claes has described the issue well. Like I said, `break` short-circuits the
>> search. If a module can provide more than one console provider, the
>> suggested stream-less replacement is **not** equivalent.
>>
>> If a module can provide mo
On Thu, 30 May 2024 16:44:21 GMT, Joe Darcy wrote:
>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update symbol files for JDK 23 build 25.
src/jdk.compiler/share/data/symbols/jdk.incubator.foreign-N.s
On Thu, 30 May 2024 08:23:25 GMT, Pavel Rappo wrote:
>> It's only semantically the same if we assume a module can only provide a
>> single `JdkConsoleProvider`, no? The `break;` disallows multiple providers
>> (for disjoint sets of charsets) in a single module.
>
> Claes has described the issue
On Thu, 30 May 2024 17:11:31 GMT, Joe Darcy wrote:
>> Get JDK 24 underway.
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The pull request now contains 18 commits:
>
> - Merge branch 'master' into JDK-8330188
> - Update symbol files for JDK 23
> Get JDK 24 underway.
Joe Darcy has updated the pull request with a new target base due to a merge or
a rebase. The pull request now contains 18 commits:
- Merge branch 'master' into JDK-8330188
- Update symbol files for JDK 23 build 25.
- Correct release year.
- Merge branch 'master' into
On Thu, 30 May 2024 16:15:22 GMT, Maurizio Cimadamore
wrote:
> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The
> cache was moved to `ValueLayouts::varHandle` as part of
> [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we
> want to optimiz
> Get JDK 24 underway.
Joe Darcy has updated the pull request incrementally with one additional commit
since the last revision:
Update symbol files for JDK 23 build 25.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18787/files
- new: https://git.openjdk.org/jdk/pull/1878
On Thu, 30 May 2024 16:15:22 GMT, Maurizio Cimadamore
wrote:
> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The
> cache was moved to `ValueLayouts::varHandle` as part of
> [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we
> want to optimiz
This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The
cache was moved to `ValueLayouts::varHandle` as part of
[pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we want
to optimize the common case like:
ValueLayout layout = ...
layout.varHandle().ge
On Thu, 30 May 2024 16:16:59 GMT, Scott Gibbons wrote:
>> I agree with @eme64 to postpone the integration after JDK 23 is forked in
>> one week. It is not about how you confident with code. It is size of code. I
>> did only limited (tier1-4) testing in our infra which did not cover all our
>>
On Thu, 30 May 2024 16:10:53 GMT, Vladimir Kozlov wrote:
>> About the fuzzer: we have it in our closed tests. But I think it comes from
>> this: https://github.com/shipilev/JavaFuzzer
>
> I agree with @eme64 to postpone the integration after JDK 23 is forked in one
> week. It is not about how y
On Thu, 30 May 2024 16:03:29 GMT, Emanuel Peter wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix bug number in tests
>
> src/hotspot/cpu/x86/c2_stubGenerator_x86_64_string.cpp line 2:
>
>> 1: /*
>> 2: * Copyr
On Thu, 30 May 2024 15:16:34 GMT, Emanuel Peter wrote:
>> Scott Gibbons has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Stupid EOL at end
>> - Add @test block; fix test indentation
>
> About the fuzzer: we have it in our closed tests.
> 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 Thu, 30 May 2024 15:48:50 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 Thu, 30 May 2024 15:33:27 GMT, Emanuel Peter wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments
>
> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 33:
>
>> 31:
>> 32: /* @test
>> 33: * @
On Thu, 30 May 2024 15:34:17 GMT, Emanuel Peter wrote:
>> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 25:
>>
>>> 23:
>>> 24: /* @test
>>> 25: * @bug 4162796 4162796 8320448
>>
>> Suggestion:
>>
>> * @bug 8320448
>
> As I said above: I never add old bug numbers to new tests. But h
> 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
> 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, 8 May 2024 09:40:38 GMT, Alan Bateman wrote:
> 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
On Thu, 30 May 2024 15:33:16 GMT, Emanuel Peter wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments
>
> test/jdk/java/lang/StringBuffer/ECoreIndexOf.java line 25:
>
>> 23:
>> 24: /* @test
>> 25: * @
On Thu, 30 May 2024 15:30:45 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 Thu, 30 May 2024 15:30:26 GMT, Emanuel Peter wrote:
>> Done.
>
>> Done.
>
> I still see the numbers `4162796 4162796`. I'm not sure if this bug number is
> relevant. But certainly it should only be mentioned once ;)
I never add old bug number to new tests...
-
PR Review Commen
On Thu, 30 May 2024 15:21:10 GMT, Scott Gibbons wrote:
> Done.
I still see the numbers `4162796 4162796`. I'm not sure if this bug number is
relevant. But certainly it should only be mentioned once ;)
-
PR Review Comment: https://git.openjdk.org/jdk/pull/16753#discussion_r16209601
> 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 Thu, 30 May 2024 13:50:01 GMT, Emanuel Peter wrote:
>> Scott Gibbons has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Stupid EOL at end
>> - Add @test block; fix test indentation
>
> test/jdk/java/lang/String/IndexOf.java line 25:
>
On Thu, 30 May 2024 13:19:57 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 Thu, 30 May 2024 14:57:35 GMT, Scott Gibbons wrote:
>>> Control question: Are we confident with this potentially going into JDK 23
>>> or should we rather postpone to JDK 24? The fork is next week.
>>
>> I would hold off. @asgibbons it may pass our tests, and your extensive
>> testing. But
On Thu, 30 May 2024 13:56:30 GMT, Emanuel Peter wrote:
>> Control question: Are we confident with this potentially going into JDK 23
>> or should we rather postpone to JDK 24? The fork is next week.
>
>> Control question: Are we confident with this potentially going into JDK 23
>> or should we
On Thu, 30 May 2024 12:32:22 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address the issue
>> noted in https://bugs.openjdk.org/browse/JDK-8210471?
>>
>> `java.util.zip.Inflater` when instantiated will hold on the native resources
>> which are freed o
On Thu, 30 May 2024 13:56:30 GMT, Emanuel Peter wrote:
>> Control question: Are we confident with this potentially going into JDK 23
>> or should we rather postpone to JDK 24? The fork is next week.
>
>> Control question: Are we confident with this potentially going into JDK 23
>> or should we
On Fri, 24 May 2024 01:08:03 GMT, Alexander Matveev
wrote:
> This issue is reproducible with and without `--mac-sign`. jpackage will
> "_ad-hoc_" sign application bundle when `--mac-sign` is not specified by
> using pseudo-identity "_-_". This is why jpackage tries to sign added files
> and t
On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad wrote:
> Extracting duplicate method references to static field reduce proxy class
> spinning and loading. In this case 2 less classes loaded when using
> `findAny()` on each type of stream.
Vicente filed a bug on javac to investigate this:
htt
On Wed, 29 May 2024 15:35:41 GMT, Alan Bateman wrote:
>> 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
> 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 Thu, 30 May 2024 12:50:36 GMT, Claes Redestad wrote:
> Extracting duplicate method references to static field reduce proxy class
> spinning and loading. In this case 2 less classes loaded when using
> `findAny()` on each type of stream.
For constant method reference, the solution is to use
On Thu, 30 May 2024 13:19:57 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 Thu, 30 May 2024 12:58:27 GMT, Scott Gibbons wrote:
>> test/jdk/java/lang/String/IndexOf.java line 35:
>>
>>> 33: * @requires vm.cpu.features ~= ".*avx2.*"
>>> 34: * @requires vm.compiler2.enabled
>>> 35: * @run main/othervm -XX:+IgnoreUnrecognizedVMOptions -Xcomp
>>> -XX:-TieredCompilati
On Thu, 30 May 2024 06:25:32 GMT, Tobias Hartmann wrote:
> Control question: Are we confident with this potentially going into JDK 23 or
> should we rather postpone to JDK 24? The fork is next week.
I would hold off. @asgibbons it may pass our tests, and your extensive testing.
But you never k
On Thu, 30 May 2024 13:03:06 GMT, Scott Gibbons wrote:
>> Would be a shame to spend so much time on writing a test and then not apply
>> it everywhere ;)
>
> I'll add a separate @test block to this file. It was, however, written
> specifically tuned for the new algorithm to exercise known edge
On Thu, 30 May 2024 13:33:40 GMT, Scott Gibbons wrote:
>> Control question: Are we confident with this potentially going into JDK 23
>> or should we rather postpone to JDK 24? The fork is next week.
>
> Thank you all for the comments. @TobiHartmann I'm comfortable with this
> going into JDK 23
Consider these two programs:
public class SystemPrint {
public static void main(String... args) {
System.err.println("Hello!");
}
}
and:
public class IOPrint {
public static void main(String... args) {
java.io.IO.println("Hello!");
}
}
They do the same conceptu
On Thu, 30 May 2024 12:50:36 GMT, Claes Redestad wrote:
> Extracting duplicate method references to static field reduce proxy class
> spinning and loading. In this case 2 less classes loaded when using
> `findAny()` on each type of stream.
Marked as reviewed by liach (Author).
Indeed, CallSit
On Thu, 30 May 2024 13:04:46 GMT, Chen Liang wrote:
> Should we extract them to private static utility methods for potential
> laziness support in the future?
Ideally we shouldn't have to do any of this. I thought such method references
were already de-duplicated in javac - at least within the
On Thu, 30 May 2024 06:25:32 GMT, Tobias Hartmann wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove duplicate vm.compiler2.enabled
>
> Control question: Are we confident with this potentially going into JDK 2
1 - 100 of 120 matches
Mail list logo
