On Mon, 12 Apr 2021 23:01:24 GMT, Naoto Sato wrote:
>> Please review the changes for the subject issue. This has been suggested in
>> a recent discussion thread for the JEP 400
>> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
>> A CSR has also been
Hi Joe,
Thanks for your nice sharing.
Very glad to know that the Java library implementation of pow does delegate to
sqrt while respecting the relevant special cases.
This implementation [1] has set a good example for us which means it's safe to
replace pow(x, 0.5) with sqrt(x) for all x >
On Sun, 11 Apr 2021 07:14:07 GMT, Tagir F. Valeev wrote:
>> With the introduction of `toList()`, preserving the SIZED characteristics in
>> more cases becomes more important. This patch preserves SIZED on `skip()`
>> and `limit()` operations, so now every combination of
>>
On Sun, 11 Apr 2021 07:14:07 GMT, Tagir F. Valeev wrote:
>> With the introduction of `toList()`, preserving the SIZED characteristics in
>> more cases becomes more important. This patch preserves SIZED on `skip()`
>> and `limit()` operations, so now every combination of
>>
On Mon, 12 Apr 2021 21:12:08 GMT, Naoto Sato wrote:
>> src/java.base/share/classes/java/io/Console.java line 397:
>>
>>> 395: /**
>>> 396: * Returns the {@link java.nio.charset.Charset Charset} object
>>> used in
>>> 397: * this {@code Console}.
>>
>> The Console is a singleton
> Please review the changes for the subject issue. This has been suggested in
> a recent discussion thread for the JEP 400
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
> A CSR has also been drafted, and comments are welcome
>
On Sun, 11 Apr 2021 10:25:47 GMT, Doug Simon wrote:
>> Vladimir Kozlov 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 three additional
>>
> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to
> Java-based JIT compiler (Graal) from JDK:
>
> - `jdk.internal.vm.compiler` — the Graal compiler
> - `jdk.internal.vm.compiler.management` — Graal's `MBean`
> - `test/hotspot/jtreg/compiler/graalunit` — Graal's
On Mon, 12 Apr 2021 20:18:46 GMT, Alexander Matveev
wrote:
> This is regression from JDK-8242302. Fixed by setting java.library.path to
> same values as it was before JDK-8242302.
Marked as reviewed by asemenyuk (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3443
On Mon, 12 Apr 2021 19:45:24 GMT, Ian Graves wrote:
> Fixes a bug where the compensated sum should be negated when added together
> in the merge step of a given collector. This impacts accuracy of parallel
> summations with Double streams and creates larger deviations from a standard
>
On Mon, 12 Apr 2021 19:45:24 GMT, Ian Graves wrote:
> Fixes a bug where the compensated sum should be negated when added together
> in the merge step of a given collector. This impacts accuracy of parallel
> summations with Double streams and creates larger deviations from a standard
>
On Sun, 11 Apr 2021 13:44:05 GMT, Alan Bateman wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reflected the review comments.
>
> src/java.base/share/classes/java/io/Console.java line 397:
>
>> 395: /**
>> 396:
> Please review the changes for the subject issue. This has been suggested in
> a recent discussion thread for the JEP 400
> [[1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075214.html)].
> A CSR has also been drafted, and comments are welcome
>
Fixes a bug where the compensated sum should be negated when added together in
the merge step of a given collector. This impacts accuracy of parallel
summations with Double streams and creates larger deviations from a standard
sequential (ie non-parallel) compensated summation.
-
This is regression from JDK-8242302. Fixed by setting java.library.path to same
values as it was before JDK-8242302.
-
Commit messages:
- 8263157: [macos]: java.library.path is being set incorrectly
Changes: https://git.openjdk.java.net/jdk/pull/3443/files
Webrev:
On Thu, 18 Mar 2021 21:03:20 GMT, Rafael Winterhalter
wrote:
> 8263763: The constructor of an enumeration prefixes with two synthetic
> arguments for constant name and ordinal index. For this reason, the
> constructor annotations need to be shifted two indices to the right, such
> that the
On Mon, 12 Apr 2021 17:18:36 GMT, Vladimir Kozlov wrote:
>> make/common/Modules.gmk line 68:
>>
>>> 66:
>>> 67: # Filter out Graal specific modules
>>> 68: MODULES_FILTER += jdk.internal.vm.compiler
>>
>> If we are unconditionally filtering out these modules, then why leave the
>>
On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Java-based JIT compiler (Graal) from JDK:
>>
>> - `jdk.internal.vm.compiler` — the Graal compiler
>> - `jdk.internal.vm.compiler.management` — Graal's
On Fri, 5 Feb 2021 21:24:34 GMT, Rafael Winterhalter
wrote:
> When a class is compiled against a version of an annotation that is later
> loaded in an incompatible manner where an enum-typed member is changed into
> an annotation or vice versa, the reflection API currently throws a
>
On Fri, 2 Apr 2021 12:33:03 GMT, Jaroslav Bachorik
wrote:
>> With this change it becomes possible to surface various cgroup level metrics
>> (available via `jdk.internal.platform.Metrics`) as JFR events.
>>
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is
>>
On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary wrote:
>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code,
>> the details of which can be seen in
>> [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number
>> JNDI methods under
Hello,
Adding some additional context, more recent versions of the IEEE 754
standard have given explicit recommendations for math library function
definitions, including pow. The Java definitions of those methods long
predate the IEEE 754 coverage and there are a small number of
differences,
On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary wrote:
>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code,
>> the details of which can be seen in
>> [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number
>> JNDI methods under
On Mon, 12 Apr 2021 16:18:32 GMT, Erik Joelsson wrote:
>> Vladimir Kozlov 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 three additional
>>
On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary wrote:
>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code,
>> the details of which can be seen in
>> [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number
>> JNDI methods under
Hi Bernd,
On 4/9/21 5:21 PM, Bernd Eckenfels wrote:
Hello,
I like the API, it is useful, however not enough to replace the defaultCharset
once the Change to UTF8 is done. You still need a way to query the platforms
file encoding (especially on Windows).
Initially I thought it would be
On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote:
>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related
>> to Java-based JIT compiler (Graal) from JDK:
>>
>> - `jdk.internal.vm.compiler` — the Graal compiler
>> - `jdk.internal.vm.compiler.management` — Graal's
On Mon, 12 Apr 2021 14:09:55 GMT, Conor Cleary wrote:
>> ### Description
>> This fix is part of a previous effort to both cleanup/modernise JNDI code,
>> the details of which can be seen in
>> [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number
>> JNDI methods under
On Mon, 12 Apr 2021 10:45:20 GMT, Claes Redestad wrote:
> Desugaring the single-case switch in MethodHandleNatives::canBeCalledVirtual
> is a cleanup and minimal startup improvement on apps spinning up
> MethodHandles.
Marked as reviewed by mchung (Reviewer).
-
PR:
Hello,
I'm just curious about the status of the important project described by
"JEP draft: Predictable regex performance" [1].
Afaiu, there are mentions about:
* Using the native re2 library [2] via JNI, with the cons that usage
becomes kind of unnatural, like "closing" the pattern to
On Fri, 9 Apr 2021 16:30:05 GMT, Roger Riggs wrote:
>> Thanks for the suggestion Roger, I think the `privilegedGetProperty(prop,
>> default)` for the `getProperty()` method looks great.
>>
>> WRT to using it for `getInt()` and `getLong()`, I think its reasonable to
>> use other means for
> ### Description
> This fix is part of a previous effort to both cleanup/modernise JNDI code,
> the details of which can be seen in
> [JDK-8048091](https://bugs.openjdk.java.net/browse/JDK-8048091). A number
> JNDI methods under `java.naming` use Anonymous Inner Classes in cases where
> only
Hi Raffaello,
Thanks for your execllent analysis.
I agree with you now.
And I'll close the optimization PR [1] tomorrow if there is no objections.
Thanks.
Best regards,
Jie
[1] https://github.com/openjdk/jdk/pull/3404/
On 2021/4/12, 9:06 PM, "Raffaello Giulietti"
wrote:
Hi Jie,
Hi Jie,
I don't think that changing the spec of Math.pow() to be misaligned with
IEEE 754 would be a wise option. IEEE is much more pervasive than Java.
There are many aspects in IEEE that might be seen as questionable, but
at least it is a widely adopted standard.
AFAIU, the only reason
On Sat, 10 Apr 2021 20:22:56 GMT, Rafael Winterhalter
wrote:
>> 8263763: The constructor of an enumeration prefixes with two synthetic
>> arguments for constant name and ordinal index. For this reason, the
>> constructor annotations need to be shifted two indices to the right, such
>> that
On Mon, 12 Apr 2021 10:45:20 GMT, Claes Redestad wrote:
> Desugaring the single-case switch in MethodHandleNatives::canBeCalledVirtual
> is a cleanup and minimal startup improvement on apps spinning up
> MethodHandles.
Marked as reviewed by jvernee (Committer).
-
PR:
Hi Andrew H, Andrew D, and Raffaello,
Thank you all for your kind reply and helpful comments.
Now I got where the rules come from.
But I don't think the IEEE standars are reasonable to specify conflits rules.
Maybe, these computations should be open to be implementation dependent.
(If it's
On Wed, 7 Apr 2021 15:45:30 GMT, Chris Hegarty wrote:
> Avoid overflow when calculating the number of pages for large mapped segment
> sizes.
This pull request has now been integrated.
Changeset: 3c9858dd
Author:Chris Hegarty
URL: https://git.openjdk.java.net/jdk/commit/3c9858dd
Desugaring the single-case switch in MethodHandleNatives::canBeCalledVirtual is
a cleanup and minimal startup improvement on apps spinning up MethodHandles.
-
Commit messages:
- Remove switch in canBeCalledVirtual
Changes: https://git.openjdk.java.net/jdk/pull/3433/files
Webrev:
Hi Jie,
the behavior you report is the one specified by the standard IEEE 754.
Java follows this standard as closely as it can.
The standard says that
* squareRoot(-0) = -0
* squareRoot(-∞) = NaN
Also, the standard has a long lists of special cases for pow(x, y),
among them:
* pow(±0, y)
On Mon, 12 Apr 2021 08:31:51 GMT, Chris Hegarty wrote:
>> Avoid overflow when calculating the number of pages for large mapped segment
>> sizes.
>
> Chris Hegarty has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Skip testing on 32-bit
On 12/04/2021 07:51, jiefu(傅杰) wrote:
I think most people will be confused by these rules because from the
view of mathematics, Math.pow(x, 0.5) should be equal to
Math.sqrt(x).
This is already a confused situation from the point of view of
mathematics. Consider these two expressions:
> Avoid overflow when calculating the number of pages for large mapped segment
> sizes.
Chris Hegarty has updated the pull request incrementally with one additional
commit since the last revision:
Skip testing on 32-bit systems
-
Changes:
- all:
On Mon, 12 Apr 2021 02:40:27 GMT, Yi Yang wrote:
>> Hello,
>>
>> to avoid cases detected in
>> [https://github.com/openjdk/jdk/pull/2992](https://github.com/openjdk/jdk/pull/2992)
>> I propose to modify JavaDoc of `ByteArray*Stream` to explicitly mention
>> redundancy of wrapping with
Hello,
to avoid cases detected in
[https://github.com/openjdk/jdk/pull/2992](https://github.com/openjdk/jdk/pull/2992)
I propose to modify JavaDoc of `ByteArray*Stream` to explicitly mention
redundancy of wrapping with `BufferedInputStream`.
As of `InputStream` I think in notation `It is
On Mon, 5 Apr 2021 08:37:15 GMT, Сергей Цыпанов
wrote:
> Hello,
>
> to avoid cases detected in
> [https://github.com/openjdk/jdk/pull/2992](https://github.com/openjdk/jdk/pull/2992)
> I propose to modify JavaDoc of `ByteArray*Stream` to explicitly mention
> redundancy of wrapping with
Hi all,
I found Math.pow(x, 0.5) and Math.sqrt(x) would compute different values as the
following:
```
Math.pow(-0.0, 0.5) = 0.0
Math.sqrt(-0.0) = -0.0
Math.pow(Double.NEGATIVE_INFINITY, 0.5) = Infinity
Math.sqrt(Double.NEGATIVE_INFINITY) = NaN
```
The reason is that both of pow and sqrt have
47 matches
Mail list logo
