jpackage https://jdk.java.net/jpackage/ page error
Incorrect link to https://bugs.openjdk.java.net/browse/JDK-8205991 "Cannot start application (WinLauncher) if path contains non-ascii character" in notes section Link to https://bugs.openjdk.java.net/browse/JDK-8204991 "PPC64: Fix jtreg RTM tests after "8203305: Improve TM detection for enabling RTM on Linux / POWER9"" given instead
Unused method java.lang.Integer::formatUnsignedInt
Hello! It seems that there's an unused method in java.lang.Integer with the following signature: static void formatUnsignedInt(int val, int shift, char[] buf, int offset, int len) Seems it exists since pre-compact-string times [1]. The callsite was replaced in the changeset 2cd62a4bd471 [2] to the method which accepts byte[] array instead of char[], but the old method still exists. The similar method java.lang.long::formatUnsignedLong was removed in unrelated changeset 66cdb7e01a3e [3] while adapting UUID.toString() for compact strings. But Integer method still stays with us. Should we remove unused java.lang.Integer::formatUnsignedInt or am I missing something? With best regards, Tagir Valeev [1] https://bugs.openjdk.java.net/browse/JDK-8141132 [2] http://hg.openjdk.java.net/jdk/jdk/rev/2cd62a4bd471 [3] http://hg.openjdk.java.net/jdk/jdk/rev/66cdb7e01a3ecb18144a27b61c2529a7390cf1b8 [4] https://bugs.openjdk.java.net/browse/JDK-8148936
RE: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results
Hi Raffaello While I don't have feedback on the actual math, here's a few suggestions: - there's some use of non-ASCII characters in the patch. I don't think this is common in the JDK's Java sources, so you might want to replace them with their Unicode escapes. The characters are: ≤ (\u2264), ∞ (\u221e), × (\u00d7), ≥ (\u2265), … (\u2026), ≠ (\u2260), ⌊ (\u230a), ⌋ (\u230b), · (\u00b7), β (\u03b2) - there are 2 invocations of a deprecated String constructor for performance reasons. I don't know how big the performance difference is, but I would suggest replacing these invocations with `new String(bytes, StandardCharsets.US_ASCII)` instead, and filing a bug for the performance difference with the deprecated constructor - there are 2 occurrences of a typo "left-to-tight" Other than that, I can only say this is an impressive piece of work, so I hope some official Reviewers will help you add your contribution to the JDK. Kind regards Anthony From: core-libs-dev on behalf of Raffaello Giulietti Sent: Monday, May 6, 2019 2:08:48 PM To: core-libs-dev Subject: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results Hi, no new code this time, only a warm invitation to review the rather substantial patch submitted on 2019-04-18 [1] and the CSR [2]. I spent an insane amount of (unpaid) free time offering my contribution to solve a bug known since about 15 years. Thus, I think it is understandable that I'd like to see my efforts come to a successful conclusion, ideally for OpenJDK 13. Greetings Raffaello P.S. Some enjoyable properties of the novel algorithm: * No objects are instantiated, except, of course, the resulting String. * Loop-free core algorithm. * Only int and long arithmetic. * No divisions at all. * 16x speedup (jmh). * Randomized, yet reproducible deep diving tests (jtreg). * Clear, unambiguous spec. * All floats have been tested to fully meet the spec. * Fully documented in [3] or in comments. [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059783.html [2] https://bugs.openjdk.java.net/browse/JDK-8202555 [3] https://drive.google.com/open?id=1KLtG_LaIbK9ETXI290zqCxvBW94dj058
Re: Lookup.unreflectSetter/unreflectGetter and volatile fields
Hi Remi, Thanks, that was what I assumed as well. It was only because Lookup.unreflectVarHandle() was very particular about every possible modifier type. That I had a second of doubt. Best, Kasper On Sun, 16 Jun 2019 at 12:03, Remi Forax wrote: > > Hi Kasper, > as usual, a getter on a volatile field will return a method handle that does > a volatile read. > The idea of the basic methodhandles, the one for field access, method calls, > etc is to have exactly the same semantics as the bytecode equivalent, so > unreflectGetter works like getfield and unreflectSetter like putfield. > > If you want a different semantics, you can use the VarHandles. > > regards, > Rémi > > - Mail original - > > De: "Kasper Nielsen" > > À: "core-libs-dev" > > Envoyé: Dimanche 16 Juin 2019 12:16:24 > > Objet: Lookup.unreflectSetter/unreflectGetter and volatile fields > > > Hi, > > > > Can anyone tell me how Lookup.unreflectSetter(Field) and > > Lookup.unreflectGetter(Field) works with volatile fields. > > Nothing is mentioned in the Javadoc of the methods. And by looking at > > the code for Lookup I couldn't really get a clearer picture. > > > > Thanks > > Kasper
Re: Slightly faster java.util.Arrays.byteSort(byte[])
I'm not an expert, however, while your OCA (see below) is being processed I would recommend to provide more comprehensive stats. Different lengths of an array, different flavours of data: sorted, sorted in the reverse order, random, typical expected case(s), etc. It seems that this particular functionality ( sort(byte[] ) hasn't changed since the JDK 8. However, you should probably add the current JDK to your comparison. One necessary step towards making this eligible for inclusion in the JDK would be to sign the OCA https://www.oracle.com/technetwork/community/oca-486395.html Keep in mind that it is not by any means a guarantee that your change will be included. Once the OCA has been signed and processed, the code then can be discussed and evaluated by experts. -Pavel > On 14 Jun 2019, at 16:34, Rodion Efremov wrote: > > Good evening! > > I managed to improve the JDK 8 java.util.Arrays.sort(byte[]) > performance-wise [1]. The (warmed up) demonstration program produces more > or less optimistic results on arrays of 1e8 bytes: > > seed = 1560526264738 > java.util.Arrays.sort(byte[]) in 87.643701 milliseconds. > java.util.Arrays.parallelSort(byte[]) in 301.329701 milliseconds. > net.coderodde.Arrays.sort(byte[]) in 62.0763 milliseconds. > Algorithms agree: true > > I would like to hear any comments on how to make it eligible for inclusion > in JDK. > > Best regards, > Rodion E. > > References: > [1] https://gist.github.com/coderodde/493407bc1c57352b53c2aa18b5c9a7a8
Re: Slightly faster java.util.Arrays.byteSort(byte[])
Hi Rodion, A more appropriate place for your email would be the core-libs-dev mailing list, so CC'ing that list. > On 14 Jun 2019, at 16:34, Rodion Efremov wrote: > > Good evening! > > I managed to improve the JDK 8 java.util.Arrays.sort(byte[]) > performance-wise [1]. The (warmed up) demonstration program produces more > or less optimistic results on arrays of 1e8 bytes: > > seed = 1560526264738 > java.util.Arrays.sort(byte[]) in 87.643701 milliseconds. > java.util.Arrays.parallelSort(byte[]) in 301.329701 milliseconds. > net.coderodde.Arrays.sort(byte[]) in 62.0763 milliseconds. > Algorithms agree: true > > I would like to hear any comments on how to make it eligible for inclusion > in JDK. > > Best regards, > Rodion E. > > References: > [1] https://gist.github.com/coderodde/493407bc1c57352b53c2aa18b5c9a7a8
Re: Lookup.unreflectSetter/unreflectGetter and volatile fields
Hi Kasper, as usual, a getter on a volatile field will return a method handle that does a volatile read. The idea of the basic methodhandles, the one for field access, method calls, etc is to have exactly the same semantics as the bytecode equivalent, so unreflectGetter works like getfield and unreflectSetter like putfield. If you want a different semantics, you can use the VarHandles. regards, Rémi - Mail original - > De: "Kasper Nielsen" > À: "core-libs-dev" > Envoyé: Dimanche 16 Juin 2019 12:16:24 > Objet: Lookup.unreflectSetter/unreflectGetter and volatile fields > Hi, > > Can anyone tell me how Lookup.unreflectSetter(Field) and > Lookup.unreflectGetter(Field) works with volatile fields. > Nothing is mentioned in the Javadoc of the methods. And by looking at > the code for Lookup I couldn't really get a clearer picture. > > Thanks > Kasper
Lookup.unreflectSetter/unreflectGetter and volatile fields
Hi, Can anyone tell me how Lookup.unreflectSetter(Field) and Lookup.unreflectGetter(Field) works with volatile fields. Nothing is mentioned in the Javadoc of the methods. And by looking at the code for Lookup I couldn't really get a clearer picture. Thanks Kasper
Re: RFR: 8224974: Implement JEP 352
On 10/06/2019 11:09, Andrew Dinn wrote: : I have updated the Proposed Java API Changes to remove the changes to map exception signature and force region specification. They were covered in the prior enabling JIRAs/CSRs. So, the remaining two sections mention 1) the new module + package + enum and 2) the bean counting changes. The new section 1 clarifies when UnsupportedOperationException is thrown vs when IOException is thrown as part of the explanation of what the new modes are for. I also added a paragraph to the alternatives section explaining that Panama was and still is an alternative option and why we decided to proceed with this model despite it being still under consideration. I re-read the JEP, trying to put myself in the position of someone reading it for the first time in 2020. Summary section: What would you think about replacing this with a sentence that makes it clear that the JEP adds new JDK-specific file mapping modes to allow the FileChannel API create MappedByteBuffers over non-volatile memory? Goals section: I think the first paragraph could be re-worded to make it clear that the goal is to use the existing MappedByteBuffer API to access NVM. Paragraphs 2-5 split this into two sub-goals. The first suggests that it extends the MBB API but this is no longer the case. The second also hints that it adds a new API. I think these two need to be re-worded. Goal 3 and 4 are okay, although I think the 4th could be summarized as allowing mapped buffers on NVM to be tracked by the existing monitoring and management APIs. Description section It might be clearer of "Proposed Java API Changes" were renamed to "Proposed JDK-specific API changes". One other thing to mention is that I re-read the javadoc for the MBB force methods and I think we need to adjust one of the sentences in the existing (and new) methods to take account of implementation specific map modes. I've created JDK-8226203 [1] to track it. As support for implementation specific map modes is in new in Java SE 13 then it might be worth trying to get that fixed now while it is fresh in our minds. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8226203
