On Tue, 11 Jul 2023 17:21:13 GMT, Alan Bateman wrote:
> Clean backport of https://git.openjdk.org/jdk/pull/14679
This pull request has now been integrated.
Changeset: 3bb37508
Author:Alan Bateman
URL:
https://git.openjdk.org/jdk21/commit/3bb375080f0ff205a5a200d0355dbd517d29c857
Stat
On Fri, 7 Jul 2023 09:51:23 GMT, yaqsun wrote:
> The prerequisite is to install the rpmbuild command, when multiple users
> switch to write /var/tmp/*.files will have the permission forbidden.
How about JTwork(if achievable)? Files created in JTwork do not need to be
cleaned when the "rpmbuild
On Fri, 7 Jul 2023 09:51:23 GMT, yaqsun wrote:
> The prerequisite is to install the rpmbuild command, when multiple users
> switch to write /var/tmp/*.files will have the permission forbidden.
I believe the problem is the use of `%{_tmppath}` for the root of intermediate
files. Should be chang
On Tue, 11 Jul 2023 22:15:49 GMT, Alexey Semenyuk wrote:
> The change affects jpackage rpm spec template file. It is misleading to state
> that this change is `Low risk, only test changes.`
My mistake, I will update the initial comment.
-
PR Comment: https://git.openjdk.org/jdk/pu
On Fri, 7 Jul 2023 09:51:23 GMT, yaqsun wrote:
> Low risk, only test changes.
> The prerequisite is to install the rpmbuild command, when multiple users
> switch to write /var/tmp/*.files will have the permission forbidden.
How about `%{buildroot}`? Shouldn't it be user-specific as well?
-
On Fri, 7 Jul 2023 09:51:23 GMT, yaqsun wrote:
> Low risk, only test changes.
> The prerequisite is to install the rpmbuild command, when multiple users
> switch to write /var/tmp/*.files will have the permission forbidden.
The change affects jpackage rpm spec template file. It is misleading to
On Tue, 11 Jul 2023 00:40:40 GMT, Maurizio Cimadamore
wrote:
> Clean backport of https://git.openjdk.org/jdk/pull/14813
> (sorry for filing another one, I realized there was an issue with the JBS
> issues pointing the wrong way)
This pull request has now been integrated.
Changeset: ca108041
A
On Tue, 11 Jul 2023 17:36:18 GMT, Brian Burkhalter wrote:
>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes
>> no guarantee as to how the underlying output stream actually writes the
>> bytes provided to it.
>
> Brian Burkhalter has updated the pull request increment
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
On Thu, 29 Jun 2023 01:55:30 GMT, Chen Liang wrote:
>> This patch implements lazy initialization for VarHandle working on static
>> fields. It has a good initial call performance.
>>
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH
>> implementation methods. If c
On Thu, 29 Jun 2023 01:55:30 GMT, Chen Liang wrote:
>> This patch implements lazy initialization for VarHandle working on static
>> fields. It has a good initial call performance.
>>
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH
>> implementation methods. If c
On Tue, 11 Jul 2023 17:36:18 GMT, Brian Burkhalter wrote:
>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes
>> no guarantee as to how the underlying output stream actually writes the
>> bytes provided to it.
>
> Brian Burkhalter has updated the pull request increment
On Thu, 29 Jun 2023 01:55:30 GMT, Chen Liang wrote:
>> This patch implements lazy initialization for VarHandle working on static
>> fields. It has a good initial call performance.
>>
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH
>> implementation methods. If c
On Tue, 11 Jul 2023 17:36:33 GMT, Mandy Chung wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix the lazy test, thanks Jorn Vernee!
>
> test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesImplementationTest.java
>
On Tue, 11 Jul 2023 15:15:51 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo wrote:
> This PR adds an internal method to calculate hash code from the provided
> integer array, offset and length into that array, and the initial hash code
> value.
>
> Current options for calculating a hash code for int[] are inflexible. It's
On Tue, 11 Jul 2023 17:07:00 GMT, Mandy Chung wrote:
> Just to be clear, the test should pass even if it keeps Lookup as the
> referent, right?
No. The test will not because there's no reference to the `Lookup` except in
`asInterfaceInstance` itself; the `Lookup`s thus are always eligible for
On Tue, 11 Jul 2023 17:36:18 GMT, Brian Burkhalter wrote:
>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes
>> no guarantee as to how the underlying output stream actually writes the
>> bytes provided to it.
>
> Brian Burkhalter has updated the pull request increment
On Tue, 11 Jul 2023 15:15:51 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Tue, 11 Jul 2023 17:21:13 GMT, Alan Bateman wrote:
> Clean backport of https://git.openjdk.org/jdk/pull/14679
Marked as reviewed by lancea (Reviewer).
-
PR Review: https://git.openjdk.org/jdk21/pull/113#pullrequestreview-1524851331
On Tue, 11 Jul 2023 17:38:42 GMT, Mandy Chung wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix the lazy test, thanks Jorn Vernee!
>
> test/jdk/java/lang/invoke/MethodHandleProxies/ProxiesImplementationTest.java
>
On Tue, 11 Jul 2023 17:21:13 GMT, Alan Bateman wrote:
> Clean backport of https://git.openjdk.org/jdk/pull/14679
Same as 22.
-
Marked as reviewed by iris (Reviewer).
PR Review: https://git.openjdk.org/jdk21/pull/113#pullrequestreview-1524839981
> In java.time packages, clarify timeline order javadoc to mention "before" and
> "after" in the value of the `compareTo` method return values.
> Add javadoc @see tags to isBefore and isAfter methods
>
> Replace use of "negative" and positive with "less than zero" and "greater
> than zero" in j
On Tue, 11 Jul 2023 17:21:13 GMT, Alan Bateman wrote:
> Clean backport of https://git.openjdk.org/jdk/pull/14679
Marked as reviewed by darcy (Reviewer).
-
PR Review: https://git.openjdk.org/jdk21/pull/113#pullrequestreview-1524813830
> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no
> guarantee as to how the underlying output stream actually writes the bytes
> provided to it.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
81559
Thanks all for your comments.
My issue has been on writing a library (baseline with 8, but support 9+ as
well) that may take locale as a String input, and it is likely it will come in
languaceCode_countryCode format (with underscore instead of dash). My questions
started after noticing that in
Clean backport of https://git.openjdk.org/jdk/pull/14679
-
Commit messages:
- Backport 623cfcd04b0c4662e614cb6a3bf52536abc02d5a
Changes: https://git.openjdk.org/jdk21/pull/113/files
Webrev: https://webrevs.openjdk.org/?repo=jdk21&pr=113&range=00
Issue: https://bugs.openjdk.org/br
On Tue, 11 Jul 2023 17:31:24 GMT, Brian Burkhalter wrote:
>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes
>> no guarantee as to how the underlying output stream actually writes the
>> bytes provided to it.
>
> Brian Burkhalter has updated the pull request increment
On Tue, 11 Jul 2023 17:24:11 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8155902: Add verbiage to existing paragraph; remove apiNote
>
> src/java.base/share/classes/java/io/DataOutputStrea
On Tue, 11 Jul 2023 16:48:24 GMT, Brian Burkhalter wrote:
>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes
>> no guarantee as to how the underlying output stream actually writes the
>> bytes provided to it.
>
> Brian Burkhalter has updated the pull request increment
On Thu, 29 Jun 2023 18:02:00 GMT, Justin Lu wrote:
> Please review this PR, which clarifies the parameter description of
> ChoiceFormat.setChoices().
>
> `ChoiceFormat.setChoices(double[] limits, String[] formats)` claims that
> `formats` can either be "Format objects or Strings". It also clai
On Tue, 11 Jul 2023 08:15:34 GMT, Alan Bateman wrote:
> In passing, we should probably look into the inconsistency in the
> synchronization.
This can be addressed in the context of
[JDK-8295797](https://bugs.openjdk.org/browse/JDK-8295797).
-
PR Comment: https://git.openjdk.org/j
On Tue, 11 Jul 2023 15:13:49 GMT, Chen Liang wrote:
> The WeakReference should point to the impl class. The Lookup is a cheap
> wrapper, so I changed it to be created each time instead.
I won't object to keep the impl class. Just to be clear, the test should pass
even if it keeps Lookup as
On Sat, 8 Jul 2023 02:05:27 GMT, Jenny Shivayogi wrote:
> Free-ing 'buf' before two conditional return statements introduced by
> JDK-8307990
This pull request has now been integrated.
Changeset: 401c3dea
Author:Jenny Shivayogi
Committer: Aleksey Shipilev
URL:
https://git.openjdk.
> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes no
> guarantee as to how the underlying output stream actually writes the bytes
> provided to it.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
81559
On Tue, 11 Jul 2023 08:30:43 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8155902: Delete "merely"
>
> src/java.base/share/classes/java/io/DataOutputStream.java line 44:
>
>> 42: * the un
On Thu, 29 Jun 2023 01:55:30 GMT, Chen Liang wrote:
>> This patch implements lazy initialization for VarHandle working on static
>> fields. It has a good initial call performance.
>>
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH
>> implementation methods. If c
This PR adds an internal method to calculate hash code from the provided
integer array, offset and length into that array, and the initial hash code
value.
Current options for calculating a hash code for int[] are inflexible. It's
either ArraysSupport.vectorizedHashCode with an offset, length a
On Tue, 11 Jul 2023 15:15:51 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
On Sat, 1 Jul 2023 07:53:17 GMT, Swati Sharma wrote:
> The below benchmark files have scaling issues due to cache contention and
> leads to poor scaling when run on multiple threads. The patch sets the scope
> from benchmark level to thread level to fix the issue:
> - org/openjdk/bench/java/io/
On Thu, 6 Jul 2023 07:16:19 GMT, David Holmes wrote:
>> Volker Simonis has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rename new parameter according to the HS coding conventions
>
> src/hotspot/share/prims/stackwalk.cpp line 501:
>
>>
> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can
> throw an `UnsupportedOperationException` if called reflectively. Currently
> this only happens if we invoke `StackWalker.getCallerClass()` recursively
> reflectively, but this issue will become more prominent once we
On Wed, 5 Jul 2023 17:25:24 GMT, Volker Simonis wrote:
>> As the included jtreg test demonstrates, `StackWalker.getCallerClass()` can
>> throw an `UnsupportedOperationException` if called reflectively. Currently
>> this only happens if we invoke `StackWalker.getCallerClass()` recursively
>> re
On Tue, 11 Jul 2023 13:40:27 GMT, Jorn Vernee wrote:
>> @mlchung Thank you for the new round of review.
>> I have split the large test into 3 parts, testing general contracts, against
>> different types of interfaces, and implementation-related tests. The old
>> MethodHandleProxies test, which
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
> javap uses proprietary com.sun.tools.classfile library to parse class files.
>
> This patch converts javap to use Classfile API.
>
> Please review.
>
> Thanks,
> Adam
Adam Sotona has updated the pull request incrementally with one additional
commit since the last revision:
fixed code prin
On Thu, 29 Jun 2023 01:55:30 GMT, Chen Liang wrote:
>> This patch implements lazy initialization for VarHandle working on static
>> fields. It has a good initial call performance.
>>
>> We introduce a new internal API, `target()` to unpack a lazy VarHandle in VH
>> implementation methods. If c
On Sat, 8 Jul 2023 02:05:27 GMT, Jenny Shivayogi wrote:
> Free-ing 'buf' before two conditional return statements introduced by
> JDK-8307990
Marked as reviewed by rriggs (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/14809#pullrequestreview-1524357337
On Tue, 11 Jul 2023 13:16:21 GMT, Chen Liang wrote:
> 1. I think the type profile pollution only happens with the instance-field
> approach, as I recall different instance fields' MHs pollute profiling. The
> comment need to be corrected if I'm right.
What happens is not really 'profile pollut
On Fri, 7 Jul 2023 16:31:47 GMT, Mandy Chung wrote:
>> Chen Liang has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains one
>> new commit s
On Fri, 7 Jul 2023 17:15:38 GMT, Mandy Chung wrote:
>> Chen Liang has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains one
>> new commit s
> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
> implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance
> interface)
> 2. Does not allow future expansion to support SAM[^1] abstrac
On Tue, 11 Jul 2023 00:40:40 GMT, Maurizio Cimadamore
wrote:
> Clean backport of https://git.openjdk.org/jdk/pull/14813
> (sorry for filing another one, I realized there was an issue with the JBS
> issues pointing the wrong way)
Marked as reviewed by jvernee (Reviewer).
-
PR Revi
On Mon, 10 Jul 2023 18:14:16 GMT, Mandy Chung wrote:
> If more than one target method handles are used, the extra classes will
> pollute the same type profiles.
Is this the case? I thought the profile pollution happens with the impl class
holding MH in instance field approach, while JIT handle
On Fri, 7 Jul 2023 15:44:06 GMT, Brian Burkhalter wrote:
>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes
>> no guarantee as to how the underlying output stream actually writes the
>> bytes provided to it.
>
> Brian Burkhalter has updated the pull request incrementa
On Fri, 7 Jul 2023 15:44:06 GMT, Brian Burkhalter wrote:
>> Add a disclaimer to `java.io.DataOutputStream` to the effect that it makes
>> no guarantee as to how the underlying output stream actually writes the
>> bytes provided to it.
>
> Brian Burkhalter has updated the pull request incrementa
On Wed, 5 Jul 2023 14:39:08 GMT, Eric Caspole wrote:
>> The below benchmark files have scaling issues due to cache contention and
>> leads to poor scaling when run on multiple threads. The patch sets the scope
>> from benchmark level to thread level to fix the issue:
>> - org/openjdk/bench/java
On Mon, 10 Jul 2023 16:07:44 GMT, John Jiang wrote:
> Not review this PR, but just raise a question. Should a JMH test, at least in
> JDK repo, always uses `@State(Scope.Thread)`, even though it uses only one
> thread?
>
> I just looked through those JMH tests, and found all of them, like the
On Mon, 10 Jul 2023 18:28:08 GMT, Jenny Shivayogi wrote:
>> Hi @kspeeyu ,
>>
>> Thanks for fixing this issue. The fix looks good except the whitespace issue
>> already mentioned before.
>>
>> Notice that we don't use TABs for code indentation in OpenJDK. For the
>> native Hotspot sources (i.e
59 matches
Mail list logo
