Hello,
btw just a small - maybe unrelated - observation on stock Java8u40. When
benchmarking String.valueOf/Integer.toString/""+n with JMH I noticed
that the compiler aided concatenation is the fastest, but not for all
integer values. I asume this is related with the initial size of the
buffer?
h
Hi Aleksey,
Is there any additional benefit by rounding up the next multiple of 4 or 8.
That would avoid a few wasted bytes at the end of the buffer modulo the
allocation size.
Otherwise, looks fine to me also.
Roger
On 5/1/2015 10:09 AM, Aleksey Shipilev wrote:
Anyone?
-Aleksey
On 04/24
Hi
I would like to use a Java program for Windows file associations.
However, this doesn't work when the file to be opened contains non-ASCII
Unicode characters in its path.
There are several related issues about Windows Unicode support (e.g.
JDK-4488646, JDK-4519026, JDK-4900150, JDK-647536
Hi Aleksey,
I like this approach and to me the webrev looks good.
-Ulf
Am 24.04.2015 um 20:05 schrieb Aleksey Shipilev:
Hi,
This seems to be a simple one-liner fix, but the background is more
complicated. See the bug:
https://bugs.openjdk.java.net/browse/JDK-8076759
http://cr.openjdk.
Hi Chris,
There is some duplication in the descriptions of the buffer contents;
see below.
On 5/1/2015 5:54 AM, Chris Hegarty wrote:
This latest version addresses all comments so far:
/**
* Reads some bytes from the input stream into the given byte array. This
* method blocks until {@code
Anyone?
-Aleksey
On 04/24/2015 09:05 PM, Aleksey Shipilev wrote:
> Hi,
>
> This seems to be a simple one-liner fix, but the background is more
> complicated. See the bug:
> https://bugs.openjdk.java.net/browse/JDK-8076759
>
> The bottom line is that our current resizing policy in ASB is hosti
This latest version addresses all comments so far:
/**
* Reads some bytes from the input stream into the given byte array. This
* method blocks until {@code len} bytes of input data have been read, end
* of stream is detected, or an exception is thrown. The number of bytes
* actually read, po
