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 RT
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 th
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),
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 volatil
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 func
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) demonstr
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 u
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
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 an