On Fri, 2 Jul 2021 00:18:55 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 17 -> JDK 18
This pull request has now been integrated.
Changeset: b0e18679
Author:Jesper Wilhelmsson
URL:
https://git.openjdk.java.net/jdk/commit/b0e186792e816be30347dacfd88b8e55476584e7
Stats: 996
> Forwardport JDK 17 -> JDK 18
Jesper Wilhelmsson has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 133 commits:
- Merge
- 8225559: assertion error at TransTypes.visitApply
Reviewed-by: sadayapalam, jlahoda
- 8268960:
Forwardport JDK 17 -> JDK 18
-
Commit messages:
- Merge
- 8269745: [JVMCI] restore original qualified exports to Graal
- 8268566: java/foreign/TestResourceScope.java timed out
- 8260684:
vmTestbase/gc/gctests/PhantomReference/phantom002/TestDescription.java timed out
- 8269580:
On Thu, 1 Jul 2021 23:46:00 GMT, Brian Burkhalter wrote:
> Please consider this proposal to remove the fast path in
> `java.lang.Math.multiplyHigh()` the small performance improvement of which is
> eclipsed by the branch penalty.
Please refer to the issue for a benchmark and sample output
Please consider this proposal to remove the fast path in
`java.lang.Math.multiplyHigh()` the small performance improvement of which is
eclipsed by the branch penalty.
-
Commit messages:
- 8188046: java.lang.Math.mutliplyHigh does not run in constant time
Changes:
On Thu, 1 Jul 2021 21:11:44 GMT, Maurizio Cimadamore
wrote:
> The previous fix to this test which used removed the `VerifyDependency` flag
> worked well, but we're still observing rare timeouts. Looking at the test
> reports, it seems likely that slightly increasing the timeout would do the
On Thu, 1 Jul 2021 18:08:22 GMT, Brian Burkhalter wrote:
>> Please consider this proposal to add a method
>> `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and
>> `java.lang.StrictMath`.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional
On Thu, 1 Jul 2021 18:08:22 GMT, Brian Burkhalter wrote:
>> Please consider this proposal to add a method
>> `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and
>> `java.lang.StrictMath`.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional
On Thu, 1 Jul 2021 18:08:22 GMT, Brian Burkhalter wrote:
>> Please consider this proposal to add a method
>> `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and
>> `java.lang.StrictMath`.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional
> This PR-*draft* is **work in progress** and an invitation to discuss a
> possible solution for issue
> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
> yet* intended for a final review.
>
> As proposed in JDK-8265891, this PR provides an implementation for
>
The previous fix to this test which used removed the `VerifyDependency` flag
worked well, but we're still observing rare timeouts. Looking at the test
reports, it seems likely that slightly increasing the timeout would do the
trick.
-
Commit messages:
- Increase timeout for
On Thu, 1 Jul 2021 13:05:26 GMT, Alan Bateman wrote:
>> Jaikiran Pai has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> implement review suggestion - move isSelfOrParent to ZipPath class
>
>
> Please consider this proposal to add a method
> `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and
> `java.lang.StrictMath`.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8188044: Add @see links between
On Mon, 14 Jun 2021 15:42:03 GMT, Maurizio Cimadamore
wrote:
> This patch contains another minor tweak to TestResourceScope as we have seen
> this test timing out at least once (on arm64).
>
> I realized that some of the logic recently introduced in the test could lead
> to the test waiting
On Wed, 30 Jun 2021 15:45:25 GMT, Weijun Wang wrote:
>> Add a cache to record which sources have called `System::setSecurityManager`
>> and only print out warning lines once for each.
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last
On Wed, 30 Jun 2021 23:13:06 GMT, Brian Burkhalter wrote:
> Please consider this proposal to add a method
> `unsignedMultiplyHigh(long,long)` to each of `java.lang.Math` and
> `java.lang.StrictMath`.
Looks good.
-
Marked as reviewed by rriggs (Reviewer).
PR:
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung wrote:
>> This spec clarification is a follow-up to
>> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320)
>> w.r.t. reference
> Can I please get a review of this proposed fix for
> https://bugs.openjdk.java.net/browse/JDK-8251329?
>
> As noted in that issue, if a zip filesystem created on top of a jar
> containing a "./" entry is "walked" using the `Files.walkFileTree`, it leads
> to a infinite never ending iteration
On Sun, 27 Jun 2021 13:13:42 GMT, Jaikiran Pai wrote:
> Can I please get a review of this proposed fix for
> https://bugs.openjdk.java.net/browse/JDK-8251329?
>
> As noted in that issue, if a zip filesystem created on top of a jar
> containing a "./" entry is "walked" using the
On Wed, 30 Jun 2021 22:52:36 GMT, Mandy Chung wrote:
>> This spec clarification is a follow-up to
>> [JDK-8224760](https://bugs.openjdk.java.net/browse/JDK-8224760?focusedCommentId=14268320=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14268320)
>> w.r.t. reference
On Thu, 1 Jul 2021 10:38:24 GMT, Сергей Цыпанов
wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdated expression should be replaced with Long.hashCode(long) as
> In some JDK classes there's still the following hashCode() implementation:
>
> long objNum;
>
> public int hashCode() {
> return (int) objNum;
> }
>
> This outdated expression should be replaced with Long.hashCode(long) as it
>
> - uses all bits of the original value, does not discard
On Wed, 30 Jun 2021 21:38:43 GMT, Naoto Sato wrote:
> A trivial typo fix.
This pull request has now been integrated.
Changeset: 54dd510b
Author:Naoto Sato
URL:
https://git.openjdk.java.net/jdk17/commit/54dd510bd5211dc440285dd53ca0e41c85e23552
Stats: 1 line in 1 file changed: 0
On Thu, 1 Jul 2021 10:38:24 GMT, Сергей Цыпанов
wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdated expression should be replaced with Long.hashCode(long) as
> In some JDK classes there's still the following hashCode() implementation:
>
> long objNum;
>
> public int hashCode() {
> return (int) objNum;
> }
>
> This outdated expression should be replaced with Long.hashCode(long) as it
>
> - uses all bits of the original value, does not discard
On Wed, 30 Jun 2021 11:49:51 GMT, Сергей Цыпанов
wrote:
>> In some JDK classes there's still the following hashCode() implementation:
>>
>> long objNum;
>>
>> public int hashCode() {
>> return (int) objNum;
>> }
>>
>> This outdated expression should be replaced with Long.hashCode(long)
Thank you Alan and Lance. I'll update this PR shortly with the proposed
approach.
-Jaikiran
On 01/07/21 2:13 pm, Alan Bateman wrote:
On 30/06/2021 17:15, Jaikiran Pai wrote:
I understand that Alan's suggestion holds good and we should have
some logic in place which switches to using a temp
On 30/06/2021 17:15, Jaikiran Pai wrote:
I understand that Alan's suggestion holds good and we should have some
logic in place which switches to using a temp file once we notice that
the sizes we are dealing with can exceed some threshold, but I guess
that is something we need to do
28 matches
Mail list logo
