Unused method java.lang.Integer::formatUnsignedInt

2019-06-16 Thread Tagir Valeev
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

RE: [PATCH] 4511638: Double.toString(double) sometimes produces incorrect results

2019-06-16 Thread Anthony Vanelverdinghe
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: ≤

Re: Lookup.unreflectSetter/unreflectGetter and volatile fields

2019-06-16 Thread Kasper Nielsen
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

Re: Slightly faster java.util.Arrays.byteSort(byte[])

2019-06-16 Thread Pavel Rappo
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

Re: Slightly faster java.util.Arrays.byteSort(byte[])

2019-06-16 Thread Pavel Rappo
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)

Re: Lookup.unreflectSetter/unreflectGetter and volatile fields

2019-06-16 Thread Remi Forax
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

Lookup.unreflectSetter/unreflectGetter and volatile fields

2019-06-16 Thread Kasper Nielsen
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

2019-06-16 Thread Alan Bateman
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