Re: Java Floating Points.
In the spirit of repeating previous messages, I again refer interested readers to my 2018 email to core-libs-dev which addresses many of the technical points being (re)raised here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/051952.html Appeal to authority is a commonly used rhetorical technique. A worse variant of appeal to authority is when the work being cited does not in fact support the argument being put forward. Case point, the document "How Java’s Floating-Point Hurts Everyone Everywhere" https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf originally authored by Prof. Kahan and myself in 1998, does not advocate decimal-only computation. The word "decimal" appears exactly zero times in the July 30, 2004 version of the document (Prof. Kahan often revises and reposts his documents). In brief, the thesis of the "JavaHURT" paper is that the Java platform commits sins of omission by requiring IEEE 754 arithmetic while forbidding certain mandatory feature of the IEEE 754 standard and by precluding support for the 80-bit floating-point format found on contemporary x86 processors. Moral conclusions aside, it is correct that the Java platform then, as now, does not natively support those mandatory features of IEEE 754 (rounding modes, floating-point exception handling) for the built-in floating-point types float and double. No other widely used and available programming platform I know of supports those features either. In the intervening years, the 80-bit format originating with the x87 co-processor has been effectively deprecated by both Intel and AMD. While IEEE 754 is commonly thought of as a hardware standard, the designers of the standard intended it to provide a programming platform. More recent revisions of IEEE 754 have tried to make this intention clearer. Without researching the exact JDK where SSE support was first included, it was would have been at least 15 years ago, probably more. The SSE instructions do *not* support decimal floating-point computation; they are primarily, but not exclusively, about 32-bit and 64-bit binary floating-point operations: https://en.wikipedia.org/wiki/Streaming_SIMD_Extensions The POWER6 chip is one of the few that does have hardware support for decimal floating-point, a feature added in the 2008 revision of IEEE 754: https://en.wikipedia.org/wiki/Decimal_floating_point Rather than re-asking core-libs-dev every few days if the the platform stewards have suddenly decided to undertake this large, but poorly defined effort, I suggest trying you organize like minded parties, perhaps including A Z poweruserm at live.com.au, to yourselves build a library/environment/platform with the features you envision to concretely demonstrate its benefits. -Joe On 4/21/2022 11:55 PM, sminervini.prism wrote: mailto:core-libs-...@openjdk.net To core-libs, OpenJDK, JCP, and all For the sake of the consequences of the real issues it raises, I include the rebuttal to Andrew Haley's earlier comments, and I reiterate that the real need is to improve the Java software at its roots level, more so. Andrew Haley said, and we reply: 1) Firstly, it is not possible to change Java's core floating-point arithmetic in a compatible way. We certainly will not adopt decimal floating-point for Java's core arithmetic. While I don't like re-submitting this article, certainly not on this forum, there has always been this article: https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf The age of this article does not matter. It is as bearing to action in 2022 as it was then. -Even without recombiling floating point or StrictMath code, of course it could be changed, and compatibly. Runtime or compile time switches could be introduced. Key words could be introduced that may apply at many different levels. Maybe even annotations could be used for the compiler, which can already apply at any point that floating point arithmetic and StrictMath methods and fields may occur. Whevever there is a code space, there could be an annotation or a keyword. At the class or interface or static block level. At the variable, data, field and method level. Even at the main method, Thread level, Runnable or Future level, or even further. 2) Secondly, Java should not be your focus. We will not change Java's arithmetic in a way that is incompatible with other languages or which makes Java slower on existing hardware. -There could be dual mode floating point correction, implemented inside Java at any level you could like. Dual mode couldn't be incompatible with anything. 3) You must read and fully understand this before you go any further. It will require a lot of study: https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html May the Java Community Process reconsider the present floating point operations and method calls situation, based on an imperfect standard and improper workaround, and provide corrected, defaulting
RFR: 8282227: Locale information for nb is not working properly
This was caused by incorporating CLDR v39, which switched the Norwegian locale inheritance from `no` -> `nb` to `nb` ->`no` and moved the resources from `nb` to `no`, which now contradicts Java's locale fallback. Explicitly inheriting `no` from `nb` will fix the issue. - Commit messages: - 8282227: Locale information for nb is not working properly Changes: https://git.openjdk.java.net/jdk/pull/8394/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8394=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282227 Stats: 79 lines in 2 files changed: 74 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8394.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8394/head:pull/8394 PR: https://git.openjdk.java.net/jdk/pull/8394
Integrated: JDK-8285614: Fix typo in java.lang.Float
On Mon, 25 Apr 2022 22:22:29 GMT, Joe Darcy wrote: > Fix typo introduced in JDK-8261123. This pull request has now been integrated. Changeset: d435d692 Author:Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/d435d692b0bbc0164a1fd1bf3616ee61a3c1c58b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8285614: Fix typo in java.lang.Float Reviewed-by: naoto, lancea, iris - PR: https://git.openjdk.java.net/jdk/pull/8390
Re: RFR: JDK-8285614: Fix typo in java.lang.Float
On Mon, 25 Apr 2022 22:22:29 GMT, Joe Darcy wrote: > Fix typo introduced in JDK-8261123. Marked as reviewed by iris (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8390
Re: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0 [v3]
On Mon, 25 Apr 2022 14:26:17 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8284642. The fix was tested by running >> Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux >> x64. Additionally, the modified test and the test in the bug report were >> run locally. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional > commit since the last revision: > > Fix globals.hpp text That all looks good to me. Thanks, David - Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8222
Re: RFR: JDK-8285614: Fix typo in java.lang.Float
On Mon, 25 Apr 2022 22:22:29 GMT, Joe Darcy wrote: > Fix typo introduced in JDK-8261123. Marked as reviewed by lancea (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8390
Re: RFR: JDK-8285614: Fix typo in java.lang.Float
On Mon, 25 Apr 2022 22:22:29 GMT, Joe Darcy wrote: > Fix typo introduced in JDK-8261123. Marked as reviewed by naoto (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8390
RFR: JDK-8285614: Fix typo in java.lang.Float
Fix typo introduced in JDK-8261123. - Commit messages: - JDK-8285614: Fix typo in java.lang.Float Changes: https://git.openjdk.java.net/jdk/pull/8390/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8390=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8285614 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8390.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8390/head:pull/8390 PR: https://git.openjdk.java.net/jdk/pull/8390
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5]
On Thu, 21 Apr 2022 11:35:57 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default and
>> require running with `--enable-preview` to enable.
>>
>> The patch has support for x64 and aarch64 on the usual operating systems
>> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for
>> zero and some of the other ports. Additional ports can be contributed via
>> PRs against the fibers branch in the loom repo.
>>
>> There are changes in many areas. To reduce notifications/mails, the labels
>> have been trimmed down for now to hotspot, serviceability and core-libs.
>> We'll add the complete set of labels when the PR is further along.
>>
>> The changes include a refresh of java.util.concurrent and ForkJoinPool from
>> Doug Lea's CVS. These changes will probably be proposed and integrated in
>> advance of this PR.
>>
>> The changes include some non-exposed and low-level infrastructure to support
>> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to
>> make life a bit easier and avoid having to separate VM changes and juggle
>> branches at this time.
>
> Alan Bateman has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Refresh
test/jdk/jdk/internal/vm/Continuation/Basic.java line 327:
> 325:
> 326: // @Test
> 327: public void testPinnedNative() {
Are you disabling this test? if so, you can do `@Test(enabled=false)`
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v6]
On Mon, 25 Apr 2022 13:19:49 GMT, Alan Bateman wrote: >> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which >> JDK version to target. >> >> We will refresh this PR periodically to pick up changes and fixes from the >> loom repo. >> >> Most of the new mechanisms in the HotSpot VM are disabled by default and >> require running with `--enable-preview` to enable. >> >> The patch has support for x64 and aarch64 on the usual operating systems >> (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for >> zero and some of the other ports. Additional ports can be contributed via >> PRs against the fibers branch in the loom repo. >> >> There are changes in many areas. To reduce notifications/mails, the labels >> have been trimmed down for now to hotspot, serviceability and core-libs. >> We'll add the complete set of labels when the PR is further along. >> >> The changes include a refresh of java.util.concurrent and ForkJoinPool from >> Doug Lea's CVS. These changes will probably be proposed and integrated in >> advance of this PR. >> >> The changes include some non-exposed and low-level infrastructure to support >> the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to >> make life a bit easier and avoid having to separate VM changes and juggle >> branches at this time. > > Alan Bateman has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains ten commits: > > - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 > - Merge with jdk-19+19 > - Refresh > - Refresh > - Refresh > - Refresh > - Merge with jdk-19+18 > - Refresh > - Initial push Test changes look good. One question/comment below - PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12]
On Mon, 14 Mar 2022 19:12:29 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on >> int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single >> element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Improved mixed insertion sort > * Optimized insertion sort > * Improved merging sort > * Optimized soring tests waiting testing result from Laurent - PR: https://git.openjdk.java.net/jdk/pull/3938
Withdrawn: 8285255: refine StringLatin1.regionMatchesCI_UTF16
On Tue, 19 Apr 2022 21:15:29 GMT, XenoAmess wrote:
> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches
> https://github.com/openjdk/jdk/pull/8292/
>
> if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
> continue;
> }
>
> should be changed to
>
> if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) :
> c1) == Character.toLowerCase(u2)) {
> continue;
> }
>
> as:
>
> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and
> don't need a lowercase cauculation.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk/pull/8308
Re: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v3]
On Wed, 20 Apr 2022 21:08:19 GMT, XenoAmess wrote:
>> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches
>> https://github.com/openjdk/jdk/pull/8292/
>>
>> if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>> continue;
>> }
>>
>> should be changed to
>>
>> if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) :
>> c1) == Character.toLowerCase(u2)) {
>> continue;
>> }
>>
>> as:
>>
>> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
>> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and
>> don't need a lowercase cauculation.
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove = check
close as not worthy.
-
PR: https://git.openjdk.java.net/jdk/pull/8308
Re: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v3]
On Mon, 25 Apr 2022 15:10:01 GMT, Claes Redestad wrote: > Unfortunately this leads to an error for case-insensitive `regionMatches` > between a latin-1-string that contains either of `\u00b5` or `\u00ff` (these > two code-points have upper case codepoints outside of the latin-1 range) and > a UTF-16 string: > > ``` > jshell> "\u00b5".regionMatches(true, 0, "\u0100", 0, 1) > | Exception java.lang.ArrayIndexOutOfBoundsException: Index 924 out of > bounds for length 256 > |at CharacterDataLatin1.getProperties (CharacterDataLatin1.java:74) > |at CharacterDataLatin1.toLowerCase (CharacterDataLatin1.java:140) > |at StringLatin1.regionMatchesCI_UTF16 (StringLatin1.java:420) > |at String.regionMatches (String.java:2238) > |at (#4:1) > ``` @cl4es Yes, you are correct. And if change it to `CharacterDataLatin1.instance.toLowerCase(u1)`, it would strongly harm performance. - PR: https://git.openjdk.java.net/jdk/pull/8308
Regression after April Java 17 Update (mime types)
Hello, We just tried to push out the Java 17 April Update but it failed with some incompatible behavior. We found out it is caused due to a new mime-type (and a bug in Apache VFS) that JAR files could no longer be opened in an overlay (technically a JAR URL suddenly had a mime-type and therefore VFS no longer looked at the file extension). Just wanted to give a heads up in case anybody else has that problem. The change 8273655 (a backport 828109) was not mentioned in the 17.0.3 release notes (it is also in 11.0.16) from Oracle and Azul - will it show up in the OpenJDK announcement? This specific case is a changed behavior (even when it has rather unexpected negative consequences), it would be therefore good to be called out specifically. Gruss Bernd -- http://bernd.eckenfels.net
Integrated: 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double
On Fri, 22 Apr 2022 14:26:07 GMT, Raffaello Giulietti wrote: > Add useful constants specified in IEEE 754. This pull request has now been integrated. Changeset: fb605944 Author:Raffaello Giulietti Committer: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/fb605944b5b734c8b47a9122e7ab3d3dcf55f71e Stats: 52 lines in 2 files changed: 32 ins; 14 del; 6 mod 8285477: Add a PRECISION public static field to j.l.Float and j.l.Double Reviewed-by: darcy - PR: https://git.openjdk.java.net/jdk/pull/8362
Re: RFR: 8283620: System.out does not use the encoding/charset specified in the Javadoc [v2]
On Sat, 23 Apr 2022 05:53:17 GMT, David Holmes wrote:
>> Naoto Sato has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Modified the spec for the new system properties.
>
> src/java.base/share/classes/java/lang/System.java line 774:
>
>> 772: * Character encoding name for {@link System#out
>> System.out}.
>> 773: * The Java runtime can be started with the system property set
>> to {@code UTF-8},
>> 774: * starting it with the property set to another value clears to
>> undefined behavior.
>
> _leads_ to undefined behavior
Good catch! Fixed.
-
PR: https://git.openjdk.java.net/jdk/pull/8270
Re: RFR: 8283620: System.out does not use the encoding/charset specified in the Javadoc [v3]
> Promoting the internal system properties for `System.out` and `System.err` so > that users can override the encoding used for those streams to `UTF-8`, > aligning to the `Charset.defaultCharset()`. A CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixed typos. - Changes: - all: https://git.openjdk.java.net/jdk/pull/8270/files - new: https://git.openjdk.java.net/jdk/pull/8270/files/b5bcb870..a91fd9ca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8270=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8270=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8270.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8270/head:pull/8270 PR: https://git.openjdk.java.net/jdk/pull/8270
Re: System.exit deadlock if called within a hook
On Mon, Apr 25, 2022 at 9:25 AM wrote:
>
> Ok, you're right that it can raise an exception when the calling thread does
> not have the security privileges needed. But what if it had them ? Right now
> the deadlock comes from the fact is doesn't got back to the caller with an
> exception and doesn't end the current thread. My 1st proposal was to have a
> way to end the current thread. If you think that is not acceptable and prefer
> the exception solution, then something like throw new
> IllegalStateException("Shutdown in progress") which is already used when
> adding new hooks while shutting down and adjust the System.exit method
> documentation accordingly (might be dangerous since it "breaks" actual
> documented and implemented contract, might be too heavy for a change).
>
> First things first : do you think this is an issue the JVM has to solve
> (either using a destroy-current-thread solution, or a
> throw-IllegalStateException one), or do you think this was a hook misuse and
> maybe would only need maybe a clearer warning in the hooks's documentation,
> or do you think we keep everything as it is because I should have guessed
> better reading the actual documentation ?
If you're asking me personally, I think it would make a lot of sense
to throw IllegalStateException or a new subclass thereof (e.g.
`ExitInProgressException` or something). However, my opinion doesn't
count. I suspect that those whose opinions *do* count will probably
say that this would be too much of a breaking change.
--
- DML • he/him
Re: RFR: 8285255: refine StringLatin1.regionMatchesCI_UTF16 [v3]
On Wed, 20 Apr 2022 21:08:19 GMT, XenoAmess wrote:
>> some thoughts after watching 8285001: Simplify StringLatin1.regionMatches
>> https://github.com/openjdk/jdk/pull/8292/
>>
>> if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) {
>> continue;
>> }
>>
>> should be changed to
>>
>> if (((u1 == c1) ? CharacterDataLatin1.instance.toLowerCase(c1) :
>> c1) == Character.toLowerCase(u2)) {
>> continue;
>> }
>>
>> as:
>>
>> 1. c1 is LATIN1, so CharacterDataLatin1.instance.toLowerCase seems faster.
>> 2. because c1 is LATIN1, so if u1 != c1, then c1 is already lowercase, and
>> don't need a lowercase cauculation.
>
> XenoAmess has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove = check
Unfortunately this leads to an error for case-insensitive `regionMatches`
between a latin-1-string that contains either of `\u00b5` or `\u00ff` (these
two code-points have upper case codepoints outside of the latin-1 range) and a
UTF-16 string:
jshell> "\u00b5".regionMatches(true, 0, "\u0100", 0, 1)
| Exception java.lang.ArrayIndexOutOfBoundsException: Index 924 out of bounds
for length 256
|at CharacterDataLatin1.getProperties (CharacterDataLatin1.java:74)
|at CharacterDataLatin1.toLowerCase (CharacterDataLatin1.java:140)
|at StringLatin1.regionMatchesCI_UTF16 (StringLatin1.java:420)
|at String.regionMatches (String.java:2238)
|at (#4:1)
-
PR: https://git.openjdk.java.net/jdk/pull/8308
Re: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0 [v2]
On Fri, 22 Apr 2022 18:14:27 GMT, Harold Seigel wrote: >> Please review this small fix for JDK-8284642. The fix was tested by running >> Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux >> x64. Additionally, the modified test and the test in the bug report were >> run locally. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional > commit since the last revision: > > restore source, fix man page Hi David, Thanks for looking at this and for the suggested text. Please review this latest commit to fix the text in globals.hpp. Thanks, Harold - PR: https://git.openjdk.java.net/jdk/pull/8222
Re: RFR: 8284642: Unexpected behavior of -XX:MaxDirectMemorySize=0 [v3]
> Please review this small fix for JDK-8284642. The fix was tested by running > Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5 on Linux > x64. Additionally, the modified test and the test in the bug report were run > locally. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: Fix globals.hpp text - Changes: - all: https://git.openjdk.java.net/jdk/pull/8222/files - new: https://git.openjdk.java.net/jdk/pull/8222/files/5fdb220a..22185a6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8222=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8222=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8222.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8222/head:pull/8222 PR: https://git.openjdk.java.net/jdk/pull/8222
RE: System.exit deadlock if called within a hook
Ok, you're right that it can raise an exception when the calling thread does
not have the security privileges needed. But what if it had them ? Right now
the deadlock comes from the fact is doesn't got back to the caller with an
exception and doesn't end the current thread. My 1st proposal was to have a way
to end the current thread. If you think that is not acceptable and prefer the
exception solution, then something like throw new
IllegalStateException("Shutdown in progress") which is already used when adding
new hooks while shutting down and adjust the System.exit method documentation
accordingly (might be dangerous since it "breaks" actual documented and
implemented contract, might be too heavy for a change).
First things first : do you think this is an issue the JVM has to solve (either
using a destroy-current-thread solution, or a throw-IllegalStateException one),
or do you think this was a hook misuse and maybe would only need maybe a
clearer warning in the hooks's documentation, or do you think we keep
everything as it is because I should have guessed better reading the actual
documentation ?
My demo code is simple, but the environment in which it happened and being able
to understand the jstack output with lots of frameworks hooking here and there
plus some uncaught exception hanlders kicking in was really really hard. In my
case I ended up having a hook to run a delayed Runtime.halt call, which more
feels like a JVM workaround rather than a framework workaround.
Regards,
Orange Restricted
-Message d'origine-
De : David Lloyd
Envoyé : lundi 25 avril 2022 15:41
À : CATHERINOT Rémi DTSI/PFS
Cc : core-libs-dev@openjdk.java.net
Objet : Re: System.exit deadlock if called within a hook
On Mon, Apr 25, 2022 at 8:09 AM wrote:
> because it would still run finally blocks, which cannot happen for no
> return methods like System.exit and Runtime.halt
FWIW I don't think this is correct. `exit` and `halt` etc. cannot
*return* but they're definitely allowed to throw an exception
(`SecurityException` is presently specified) and thus are allowed to unwind the
stack, even through `finally` blocks.
--
- DML • he/him
_
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
Re: RFR: 8284992: Fix misleading Vector API doc for LSHR operator
On Wed, 20 Apr 2022 17:24:56 GMT, Paul Sandoz wrote:
>> Hi all,
>>
>> The Current Vector API doc for `LSHR` is
>>
>> Produce a>>>(n&(ESIZE*8-1)). Integral only.
>>
>>
>> This is misleading which may lead to bugs for Java developers.
>> This is because for negative byte/short elements, the results computed by
>> `LSHR` will be different from that of `>>>`.
>> For more details, please see
>> https://github.com/openjdk/jdk/pull/8276#issue-1206391831 .
>>
>> After the patch, the doc for `LSHR` is
>>
>> Produce zero-extended right shift of a by (n&(ESIZE*8-1)) bits. Integral
>> only.
>>
>>
>> Thanks.
>> Best regards,
>> Jie
>
> We can raise attention to that:
>
> /** Produce {@code a>>>(n&(ESIZE*8-1))}
> * (The operand and result are converted if the operand type is {@code byte}
> or {@code short}, see below). Integral only.
> * ...
> */
Hi @PaulSandoz ,
I add a piece of notice at the end of the brief description of `LSHR` since not
everyone would click and see the details without the change.
What do you think?
Thanks.
-
PR: https://git.openjdk.java.net/jdk/pull/8291
Re: RFR: 8284779: Test java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails intermittently with vthreads wrapper [v2]
On Mon, 25 Apr 2022 13:56:04 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find enclosed a patch to fix a rare intermittent failure that was >> detected while testing virtual threads. >> The issue has nothing to do with virtual threads, the test is simply missing >> a reachability fence to make sure that the parent logger is not garbage >> collected until its child logger is created. >> >> best regards, >> >> -- daniel > > Daniel Fuchs has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright year again Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/8382
Re: RFR: 8284779: Test java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails intermittently with vthreads wrapper [v2]
On Mon, 25 Apr 2022 13:52:38 GMT, Daniel Fuchs wrote: >> Hi, >> >> Please find enclosed a patch to fix a rare intermittent failure that was >> detected while testing virtual threads. >> The issue has nothing to do with virtual threads, the test is simply missing >> a reachability fence to make sure that the parent logger is not garbage >> collected until its child logger is created. >> >> best regards, >> >> -- daniel > > Daniel Fuchs has updated the pull request incrementally with one additional > commit since the last revision: > > Update copyright year again Marked as reviewed by alanb (Reviewer). test/jdk/java/util/logging/Logger/logrb/TestLogrbResourceBundle.java line 3: > 1: /* > 2: * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights > reserved. > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. I think you meant 2022 :-) - PR: https://git.openjdk.java.net/jdk/pull/8382
Re: RFR: 8284779: Test java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails intermittently with vthreads wrapper [v2]
On Mon, 25 Apr 2022 13:48:47 GMT, Alan Bateman wrote: >> Daniel Fuchs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright year again > > test/jdk/java/util/logging/Logger/logrb/TestLogrbResourceBundle.java line 3: > >> 1: /* >> 2: * Copyright (c) 2013, 2020, Oracle and/or its affiliates. All rights >> reserved. >> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > > I think you meant 2022 :-) How times fly! :-) Thanks for catching. - PR: https://git.openjdk.java.net/jdk/pull/8382
Re: RFR: 8284779: Test java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails intermittently with vthreads wrapper [v2]
> Hi, > > Please find enclosed a patch to fix a rare intermittent failure that was > detected while testing virtual threads. > The issue has nothing to do with virtual threads, the test is simply missing > a reachability fence to make sure that the parent logger is not garbage > collected until its child logger is created. > > best regards, > > -- daniel Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision: Update copyright year again - Changes: - all: https://git.openjdk.java.net/jdk/pull/8382/files - new: https://git.openjdk.java.net/jdk/pull/8382/files/0e7d60cb..191fa7ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=8382=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=8382=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8382.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8382/head:pull/8382 PR: https://git.openjdk.java.net/jdk/pull/8382
Re: System.exit deadlock if called within a hook
On Mon, Apr 25, 2022 at 8:09 AM wrote: > because it would still run finally blocks, which cannot happen for no return > methods like System.exit and Runtime.halt FWIW I don't think this is correct. `exit` and `halt` etc. cannot *return* but they're definitely allowed to throw an exception (`SecurityException` is presently specified) and thus are allowed to unwind the stack, even through `finally` blocks. -- - DML • he/him
RFR: 8284779: Test java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails intermittently with vthreads wrapper
Hi, Please find enclosed a patch to fix a rare intermittent failure that was detected while testing virtual thread. The issue has nothing to do with virtual thread, the test is simply missing a reachability fence to make sure that the parent logger is not garbage collected until its child logger is created. best regards, -- daniel - Commit messages: - 8284779: Test java/util/logging/Logger/logrb/TestLogrbResourceBundle.java fails intermittently with vthreads wrapper Changes: https://git.openjdk.java.net/jdk/pull/8382/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8382=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8284779 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8382.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8382/head:pull/8382 PR: https://git.openjdk.java.net/jdk/pull/8382
Re: RFR: 8285445: cannot open file "NUL:"
On Sat, 23 Apr 2022 15:24:13 GMT, Alan Bateman wrote: > > FWIW we fixed the same problem by simply using `NUL` instead of `NUL:`. > > Hopefully newer code can use OutputStream.nullOutputStream(). It's portable > and avoids depending on these legacy Windows specific reserved names. One possible advantage of having a "real" OS-supported `null` stream (in addition to its uses by the process subsystem) is that it could be used to efficiently drain bytes from things like sockets and pipes using transfer methods, assuming adequate JDK support. On Linux at least, the `splice` syscall is able to move bytes between socket and pipe buffers and into file buffers without copying them into user space. For `/dev/null` this means the bytes are discarded on the kernel side. - PR: https://git.openjdk.java.net/jdk/pull/8373
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v6]
> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which > JDK version to target. > > We will refresh this PR periodically to pick up changes and fixes from the > loom repo. > > Most of the new mechanisms in the HotSpot VM are disabled by default and > require running with `--enable-preview` to enable. > > The patch has support for x64 and aarch64 on the usual operating systems > (Linux, macOS, and Windows). There are stubs (calling Unimplemented) for zero > and some of the other ports. Additional ports can be contributed via PRs > against the fibers branch in the loom repo. > > There are changes in many areas. To reduce notifications/mails, the labels > have been trimmed down for now to hotspot, serviceability and core-libs. > We'll add the complete set of labels when the PR is further along. > > The changes include a refresh of java.util.concurrent and ForkJoinPool from > Doug Lea's CVS. These changes will probably be proposed and integrated in > advance of this PR. > > The changes include some non-exposed and low-level infrastructure to support > the (in draft) JEPs for Structured Concurrency and Scope Locals. This is to > make life a bit easier and avoid having to separate VM changes and juggle > branches at this time. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Refresh cf561073f48fad58e931a5285b92629aa83c9bd1 - Merge with jdk-19+19 - Refresh - Refresh - Refresh - Refresh - Merge with jdk-19+18 - Refresh - Initial push - Changes: https://git.openjdk.java.net/jdk/pull/8166/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8166=05 Stats: 104157 lines in 1144 files changed: 94155 ins; 4291 del; 5711 mod Patch: https://git.openjdk.java.net/jdk/pull/8166.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8166/head:pull/8166 PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v5]
On Fri, 22 Apr 2022 02:26:50 GMT, ExE Boss wrote:
>> Alan Bateman has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Refresh
>
> src/java.base/share/classes/java/lang/ThreadLocal.java line 179:
>
>> 177: private T get(Thread t) {
>> 178: ThreadLocalMap map = getMap(t);
>> 179: if (map != null && map != ThreadLocalMap.NOT_SUPPORTED) {
>
> Due to the way `setInitialValue` is implemented, `getMap(t)` will currently
> be called twice when `ThreadLocal`s are disabled.
>
>
>
> This method should probably be changed so that when `map ==
> ThreadLocalMap.NOT_SUPPORTED`, it simply does:
>
> return initialValue();
>
>
>
>
> Suggestion:
>
> if (map != null) {
> if (map == ThreadLocalMap.NOT_SUPPORTED) {
> return initialValue();
> }
It's benign but what you suggest may be clearer - thanks!
> src/java.base/share/classes/java/lang/ThreadLocal.java line 423:
>
>> 421: * Construct a new map without a table.
>> 422: */
>> 423: ThreadLocalMap() {
>
> It might be possible for this to be `private`:
> Suggestion:
>
> private ThreadLocalMap() {
Yes, this can be private.
-
PR: https://git.openjdk.java.net/jdk/pull/8166
Re: RFR: 8284161: Implementation of Virtual Threads (Preview) [v2]
On Fri, 15 Apr 2022 21:24:58 GMT, Paul Sandoz wrote: >> Alan Bateman has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Refresh > > src/java.base/share/classes/jdk/internal/vm/Continuation.java line 115: > >> 113: } >> 114: >> 115: private Runnable target; > > Can be final? (Does not appear to be updated by the VM, or via unsafe by some > other class) Yes, it can. - PR: https://git.openjdk.java.net/jdk/pull/8166
System.exit deadlock if called within a hook
Hi,
Exemple code to deadlock the JVM. Only Runtime.halt from within the JVM or a
SIGKILL from outside stops it. Normal kills and Ctrl-C (which is a SIGTERM)
fail to do so.
public class ExitInHookDemo {
public static void main(String...args) {
Runtime.getRuntime().addShutdownHook(new Thread("hook")
{
public void run() { System.exit(1); }
});
}
}
I've tried to more or less do a pure java patch in java.lang.Shutdown but the
only way to have a real patch would be to have Thread.destroy still there and
implemented or anything allowing Shutdown to destroy a thread. In essence,
System.exit is a no return method call. So using Thread.stop which raise a
ThreadDeath error is not enough (the method go back to the caller with the
error). Only Thread.destroy has the contract of being a no return call. Yes the
documentation said it is unsafe because it does not release locks & co, but
right now that is exactly what is happening, so Thread.destroy limitations are
acceptable. Throwing something that is not catchable, something legit to throw
but not legit to catch, even by a catch Throwable, is not enough because it
would still run finally blocks, which cannot happen for no return methods like
System.exit and Runtime.halt: try { System.exit(0); /* code that should never
be reached */ } catch (Throwable t) { /* code that should never be reached */ }
finally { /* code that should also never be reached */ }
I've searched the known/documented bugs but I either missed the fact it was
already reported, or I only got entries about removing Thread.destroy.
By the way, I'm not really asking to have Thread.destroy implemented were it is
currently defined (a public method inside Thread). I mean at least
java.lang.Shutdown should have a way to destroy Threads, even a private one.
Threads destroyed that way should make threads stuck joining the destroyed one
must be released.
I got the bug on java 1.8, oracle and openjdk ones. Not tested it one >=9 ones.
Here is what the approximation of a patch using pure java, but I'm no jdk
expert and had no access to thread destruction, so it is not perfect. The code
is from java.lang.Shutdown
static void exit(int status) {
boolean wasRunning = false; // < - - new var
boolean runMoreFinalizers = false;
synchronized (lock) {
switch (state) {
case RUNNING: /* Initiate shutdown */
state = HOOKS;
wasRunning = true; // < - - first call to System.exit, the
caller will run all of what is needed -hooks, maybe finalizers, etc.
if (status != 0) runFinalizersOnExit = false; // < - - also
moved the runFinalizersOnExit block to avoid having it changed/altered by
several threads trying to exit with different status code
break;
case HOOKS: /* Stall and halt */
break;
case FINALIZERS:
if (status != 0) {
/* Halt immediately on nonzero status */
halt(status);
} else {
/* Compatibility with old behavior:
* Run more finalizers and then halt
*/
runMoreFinalizers = runFinalizersOnExit;
}
break;
}
}
if (!wasRunning) Thread.currentThread().stop(); // < - - should be a
destroy rather than a stop. This thread is not the 1st who called System.exit,
and since it should never return, it must die asap. We are outside of the
synchronized block so if any lock remains acquired by this thread, they are
acquired by the caller which should have released them before calling exit on
the 1st place. If the caller called us while having locks, it is a caller bug,
not a Shutdown.exit one. Current implementation since it never returns (and
yield the stuck bug I report) also never release any of the locks it has too
// < - - beyond this line nothing has been modified
if (runMoreFinalizers) {
runAllFinalizers();
halt(status);
}
synchronized (Shutdown.class) {
/* Synchronize on the class object, causing any other thread
* that attempts to initiate shutdown to stall indefinitely
*/
sequence();
halt(status);
}
}
Regards,
Ogrom.
_
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange
Re: RFR: 8283620: System.out does not use the encoding/charset specified in the Javadoc [v2]
On Fri, 22 Apr 2022 18:14:18 GMT, Naoto Sato wrote:
>> Promoting the internal system properties for `System.out` and `System.err`
>> so that users can override the encoding used for those streams to `UTF-8`,
>> aligning to the `Charset.defaultCharset()`. A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Modified the spec for the new system properties.
Overall I think this looks good, assuming the typo in the spec ("clears" ->
"leads") is fixed.
-
Marked as reviewed by alanb (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/8270
Re: RFR: 8283620: System.out does not use the encoding/charset specified in the Javadoc [v2]
On Sat, 23 Apr 2022 05:55:15 GMT, David Holmes wrote: > I think Alan has a typo: "clears" -> "leads" Apologies, there was a typo in my comment on the PR. I didn't mean for the word "clears" to go into the spec. - PR: https://git.openjdk.java.net/jdk/pull/8270
