On Sat, 1 Jun 2024 05:18:17 GMT, Jaikiran Pai wrote:
>> 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
On Fri, 31 May 2024 14:55:57 GMT, Daniel Fuchs wrote:
> HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests verify that
> loggers are GC'ed (or not GC'ed) after a reset or an update. For that they
> poll a ReferenceQueue in a loop. The number of iteration is adjusted
> according to
> 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
Can I please get a review of this doc-only change which proposes to improve the
code snippet that's in `java.util.zip.Deflater` and `java.util.zip.Inflater` to
better explain the usage of those classes? This addresses
https://bugs.openjdk.org/browse/JDK-8026127.
The commit in the PR cleans up
On Fri, 31 May 2024 14:05:07 GMT, Alexey Semenyuk wrote:
> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app
> launcher instead of raw Executor. This makes MainClassTest test run app
> launchers with retries. This change addresses the primary issue.
>
> Fix
On Fri, 17 May 2024 12:01:23 GMT, Chen Liang wrote:
> Core reflection's generic signature parsing uses an ancient library with
> outdated visitor pattern on a tree model and contains unnecessary
> boilerplates. This is a duplication of ClassFile API's signature model. We
> should just move to
On Thu, 9 May 2024 02:09:50 GMT, xiaotaonan wrote:
> Clean up non-standard use of /// comments in `java.base`
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/19151
Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app
launcher instead of raw Executor. This makes MainClassTest test run app
launchers with retries. This change addresses the primary issue.
Fix inconsistencies in HelloApp.AppOutputVerifier class. It used to provide API
On Fri, 31 May 2024 14:05:07 GMT, Alexey Semenyuk wrote:
> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app
> launcher instead of raw Executor. This makes MainClassTest test run app
> launchers with retries. This change addresses the primary issue.
>
> Fix
Yes you can file an Apple bug report but I think these days it requires a
developer account to get to the bug reporter.
The indicated documentation doesn’t mention anything about your own
files/directories. So I think a bug report might be appropriate. One in but the
other out doesn’t seem
On Fri, 17 May 2024 12:01:23 GMT, Chen Liang wrote:
> Core reflection's generic signature parsing uses an ancient library with
> outdated visitor pattern on a tree model and contains unnecessary
> boilerplates. This is a duplication of ClassFile API's signature model. We
> should just move to
On Sat, 18 May 2024 05:24:16 GMT, ExE Boss wrote:
>> Core reflection's generic signature parsing uses an ancient library with
>> outdated visitor pattern on a tree model and contains unnecessary
>> boilerplates. This is a duplication of ClassFile API's signature model. We
>> should just move
Core reflection's generic signature parsing uses an ancient library with
outdated visitor pattern on a tree model and contains unnecessary boilerplates.
This is a duplication of ClassFile API's signature model. We should just move
to ClassFile API, which is more throughoutly tested as well.
To
On Fri, 17 May 2024 12:01:23 GMT, Chen Liang wrote:
> Core reflection's generic signature parsing uses an ancient library with
> outdated visitor pattern on a tree model and contains unnecessary
> boilerplates. This is a duplication of ClassFile API's signature model. We
> should just move to
On Tue, 7 May 2024 22:23:48 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 keep
On Fri, 31 May 2024 21:36:56 GMT, Nir Lisker wrote:
> I see, but it doesn't say where to put license files, which are usually in
> the root. Do you know where these belong?
No idea.
-
PR Comment: https://git.openjdk.org/jdk/pull/19377#issuecomment-2143025767
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
>>
On Mon, 13 Nov 2023 22:31:16 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.
>
> A
On Fri, 31 May 2024 20:43:45 GMT, Nir Lisker wrote:
> > > For your example. This almost seems like an Apple bug if you can add a
> > > directory to the Contents directory but not a file?
> >
> >
> > Not sure if it is an Apple bug.
>
> Can this be reported to Apple somehow?
I do not think
On Fri, 31 May 2024 18:39:33 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Sat, 25 May 2024 01:12:56 GMT, Alexander Matveev
wrote:
> > For your example. This almost seems like an Apple bug if you can add a
> > directory to the Contents directory but not a file?
>
> Not sure if it is an Apple bug.
Can this be reported to Apple somehow?
-
PR Comment:
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
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
On Thu, 30 May 2024 14:21:51 GMT, Alexey Semenyuk wrote:
>> Alexander Matveev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8332110: jpackage tries to sign added files without the --mac-sign option
>> [v2]
>
>
On Fri, 31 May 2024 18:39:33 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Fri, 31 May 2024 18:39:33 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Fri, 31 May 2024 17:59:18 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
> Class[0] instances. This cloning is intended to prevent callers from
> changing array contents, but many Methods have zero exceptions or zero
> parameters, and returning the original `Class[0]` is sufficient.
>
>
> 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:
> -
On Fri, 31 May 2024 17:59:18 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
> Class[0] instances. This cloning is intended to prevent callers from
> changing array contents, but many Methods have zero exceptions or zero
> parameters, and returning the original `Class[0]` is sufficient.
>
>
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
On Fri, 31 May 2024 16:26:50 GMT, Per Minborg wrote:
> Would it make sense to add some tests that assert, `VarHandle` objects get
> cached?
We can't - at least not easily. As explained in the new comment, the var
handles cached by this method are "raw" and always adapted by some other API.
> 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 = ...
>
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
On Fri, 31 May 2024 16:18:33 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
> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
> Class[0] instances. This cloning is intended to prevent callers from
> changing array contents, but many Methods have zero exceptions or zero
> parameters, and returning the original `Class[0]` is sufficient.
>
>
On Fri, 31 May 2024 16:53:36 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie wrote:
> 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
>
> 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 Fri, 31 May 2024 16:21:36 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but smany Methods have zero exceptions or zero
>> parameters,
On Tue, 28 May 2024 17:25:34 GMT, Sean Gwizdak wrote:
> Improve the speed of Method.hashCode by caching the hashcode on first use.
> I've seen an application where Method.hashCode is a hot path, and this is a
> fairly simple speedup. The memory overhead is low.
>
> This addresses issue
>
On Wed, 29 May 2024 15:03:15 GMT, Sean Gwizdak wrote:
>> src/java.base/share/classes/java/lang/reflect/Method.java line 99:
>>
>>> 97: private Method root;
>>> 98: // Hash code of this object
>>> 99: private int hash;
>>
>> We can declare this field
On Wed, 29 May 2024 15:20:56 GMT, Chen Liang wrote:
> Also, have you considered micro-optimize Constructor.hashCode too? Given its
> similar status to Method.
Not at this time. This PR is motivated by observing Method.hashCode as a
hotspot in a Spring heavy application when migrating to an
Improve the speed of Method.hashCode by caching the hashcode on first use. I've
seen an application where Method.hashCode is a hot path, and this is a fairly
simple speedup. The memory overhead is low.
This addresses issue
[JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249).
Before:
On Fri, 31 May 2024 16:18:33 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
On Wed, 22 May 2024 09:44:18 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
>>
On Fri, 31 May 2024 16:18:01 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,
> 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.
> 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 = ...
>
On Fri, 31 May 2024 16:15:12 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
On Fri, 31 May 2024 00:57:18 GMT, Jaikiran Pai wrote:
> 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
Thanks a lot, Chen
-Zhengyu
From: Chen Liang
Date: Friday, May 31, 2024 at 10:19 AM
To: Zhengyu Gu
Cc: core-libs-dev@openjdk.org
Subject: Re: Question on Lambda function
[External Email]
Hi Zhengyu,
This implementation is actually quite good in terms of
HandlersOnComplexResetUpdate and HandlersOnComplexUpdate tests verify that
loggers are GC'ed (or not GC'ed) after a reset or an update. For that they poll
a ReferenceQueue in a loop. The number of iteration is adjusted according to
the jtreg timeout factor. However, the logic in the test did
On Fri, 31 May 2024 14:24:56 GMT, Doug Lea wrote:
>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2024:
>>
>>> 2022: }
>>> 2023: if (pb == (pb = b)) // base
>>> unchanged
>>> 2024:
On Thu, 9 May 2024 19:52:12 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the
On Thu, 30 May 2024 19:14:43 GMT, Magnus Ihse Bursie wrote:
> 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
>
On Fri, 31 May 2024 14:08:49 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reconcile changes
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2075:
>
>> 2073:
On Fri, 31 May 2024 14:04:50 GMT, Viktor Klang wrote:
>> Doug Lea has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reconcile changes
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2024:
>
>> 2022:
Hi Zhengyu,
This implementation is actually quite good in terms of performance and
cost. One improvement you can have is to replace the `invoke`
with `invokeExact` (and remember to call MethodHandle.asType() before
passing into your anonymous class).
Unfortunately, it will be somewhat slow due to
On Fri, 31 May 2024 13:18:33 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
Hi Chen,
Do you see any pros and cons of wrapping a MethodHandle, e.g.
new Function() {
@Override
public C apply(D t) {
try {
return (C) handle.invoke(t);
} catch (Throwable e) {
}
}
vs using MethodHandleProxies.asInterfaceInstance() ?
I would really
On Fri, 31 May 2024 13:18:33 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
On Thu, 30 May 2024 12:14:53 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 only
On Fri, 31 May 2024 11:03:18 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
On Fri, 31 May 2024 13:04:03 GMT, David M. Lloyd wrote:
> The new method additions ClassReader.readEntryOrNull(int, Class) and
> ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should
> be `@since 23`.
Thank you for the fix.
-
Marked as reviewed by asotona
On Wed, 22 May 2024 07:56:26 GMT, Alan Bateman wrote:
>>> @bchristi-git Just checking in—we're waiting for CSR-approval here before
>>> integrating? 樂
>>
>> Indeed - can't move forward without a CSR. Also wouldn't mind more reviewer
>> ✔️s.
>
>> Indeed - can't move forward without a CSR.
> 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
On Fri, 31 May 2024 13:04:03 GMT, David M. Lloyd wrote:
> The new method additions ClassReader.readEntryOrNull(int, Class) and
> ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should
> be `@since 23`.
Marked as reviewed by liach (Author).
-
PR Review:
The new method additions ClassReader.readEntryOrNull(int, Class) and
ConstantPool.entryByIndex(int, Class) have incorrect since tags; they should be
`@since 23`.
-
Commit messages:
- 812: Incorrect since tags on new ClassReader and ConstantPool methods
Changes:
On Thu, 30 May 2024 21:47:02 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/classfile/ClassReader.java line 142:
>>
>>> 140: * @throws ConstantPoolException if the index is out of range of
>>> the
>>> 141: * constant pool size, or zero, or the entry is not of
On Fri, 31 May 2024 11:03:18 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
On Fri, 31 May 2024 10:35:11 GMT, Lance Andersen wrote:
> Personally, I would have had each assertThrows as its own test, as if one
> fails(which should not in this case) then the rest of the assertions are
> never executed until the first failure is addressed.
I have now updated the PR to
> 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 only when `Inflater.end()` is called. The constructor of
>
On Fri, 31 May 2024 10:09:20 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
> 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
> 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 only when `Inflater.end()` is called. The constructor of
>
This patch changes the algorithm of `Node::dominates` to make the result more
precise, and allows the iterators of `ConcurrentHashMap` to be scalar replaced.
The previous algorithm will return a conservative result when encountering a
dead control flow, and only try the first two input paths of
Can I please get a review of this test-only change which addresses
https://bugs.openjdk.org/browse/JDK-8333130?
There are a couple of tests `NativeMethodPrefixApp` and `RetransformApp` under
`test/jdk/java/lang/instrument/` which launch the app/test with a
`-javaagent:` pointing to a test
On Thu, 4 Apr 2024 15:13:46 GMT, Adam Sotona wrote:
> 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`
On Thu, 9 May 2024 19:52:12 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the
> 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
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
>
83 matches
Mail list logo
