On Fri, 19 Feb 2021 14:24:34 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert JavaLangAccessImpl changes
>
> Marked as reviewed by naoto (Reviewer).
Thanks for reviewing!
-
On Thu, 18 Feb 2021 23:16:00 GMT, Claes Redestad wrote:
>> This patch exposes a couple of intrinsics used by String to speed up ASCII
>> checking and byte[] -> char[] inflation, which can be used by latin1 and
>> ASCII-compatible CharsetDecoders to speed up decoding operations.
>>
>> -
On Thu, 18 Feb 2021 23:16:00 GMT, Claes Redestad wrote:
>> This patch exposes a couple of intrinsics used by String to speed up ASCII
>> checking and byte[] -> char[] inflation, which can be used by latin1 and
>> ASCII-compatible CharsetDecoders to speed up decoding operations.
>>
>> -
On Thu, 18 Feb 2021 23:16:54 GMT, Claes Redestad wrote:
> Turns out the native code called by `SystemProps.initProperties();` can
> initialize a `CharsetDecoder` if `sun.jnu.encoding` is set to certain values,
> and this tripped up the initialization to cause `getJavaLangAccess` to be
>
On Wed, 17 Feb 2021 17:19:58 GMT, Alan Bateman wrote:
> > Right, I'm not exactly sure why the more limited changes I attempted in
> > [5f4e87f](https://github.com/openjdk/jdk/commit/5f4e87f50f49e64b8616063c176ea35632b0347e)
> > failed. In that change I simply changed the initialization order,
> This patch exposes a couple of intrinsics used by String to speed up ASCII
> checking and byte[] -> char[] inflation, which can be used by latin1 and
> ASCII-compatible CharsetDecoders to speed up decoding operations.
>
> - Fast-path implemented for all standard charsets, with up to 10x
On Wed, 17 Feb 2021 17:22:21 GMT, Alan Bateman wrote:
>>> Right, I'm not exactly sure why the more limited changes I attempted in
>>> [5f4e87f](https://github.com/openjdk/jdk/commit/5f4e87f50f49e64b8616063c176ea35632b0347e)
>>> failed. In that change I simply changed the initialization order,
On Wed, 17 Feb 2021 17:19:58 GMT, Alan Bateman wrote:
>> Great improvement! Looks good to me overall. I wondered about the changes in
>> JLA as Alan already mentioned.
>
>> Right, I'm not exactly sure why the more limited changes I attempted in
>>
On Tue, 16 Feb 2021 19:51:21 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert rem assertions
>
> Great improvement! Looks good to me overall. I wondered about the changes in
> JLA as Alan
> This patch exposes a couple of intrinsics used by String to speed up ASCII
> checking and byte[] -> char[] inflation, which can be used by latin1 and
> ASCII-compatible CharsetDecoders to speed up decoding operations.
>
> - Fast-path implemented for all standard charsets, with up to 10x
On Tue, 16 Feb 2021 19:48:09 GMT, Naoto Sato wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert rem assertions
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 48:
>
>> 46:
On Mon, 15 Feb 2021 15:19:01 GMT, Claes Redestad wrote:
>> This patch exposes a couple of intrinsics used by String to speed up ASCII
>> checking and byte[] -> char[] inflation, which can be used by latin1 and
>> ASCII-compatible CharsetDecoders to speed up decoding operations.
>>
>> -
On Tue, 16 Feb 2021 15:05:33 GMT, Alan Bateman wrote:
> The reformatting changes to StreamEncoder/StreamDecoder make it hard to see
> if there are any actual changes. Is there anything we should look at? It's
> okay to include this cleanup, I can't tell what happened with this source
> file.
On Tue, 16 Feb 2021 15:05:33 GMT, Alan Bateman wrote:
>>> > Is there a reason
>>> > `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[], int, byte[],
>>> > int, int)` wasn't moved to `JavaLangAccess` as well?
>>>
>>> Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders
On Tue, 16 Feb 2021 13:45:41 GMT, Claes Redestad wrote:
>>> Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[],
>>> int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well?
>>
>> Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem
>>
On Mon, 15 Feb 2021 20:34:53 GMT, Claes Redestad wrote:
> > Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[],
> > int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well?
>
> Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem
> very
On Mon, 15 Feb 2021 19:56:32 GMT, Philippe Marschall
wrote:
> Is there a reason `sun.nio.cs.ISO_8859_1.Encoder#implEncodeISOArray(char[],
> int, byte[], int, int)` wasn't moved to `JavaLangAccess` as well?
Exposing StringUTF16.compress for Latin-1 and ASCII-compatible encoders seem
very
On Mon, 15 Feb 2021 11:30:54 GMT, Claes Redestad wrote:
>> This patch exposes a couple of intrinsics used by String to speed up ASCII
>> checking and byte[] -> char[] inflation, which can be used by latin1 and
>> ASCII-compatible CharsetDecoders to speed up decoding operations.
>>
>> -
> This patch exposes a couple of intrinsics used by String to speed up ASCII
> checking and byte[] -> char[] inflation, which can be used by latin1 and
> ASCII-compatible CharsetDecoders to speed up decoding operations.
>
> - Fast-path implemented for all standard charsets, with up to 10x
This patch exposes a couple of intrinsics used by String to speed up ASCII
checking and byte[] -> char[] inflation, which can be used by latin1 and
ASCII-compatible CharsetDecoders to speed up decoding operations.
- Fast-path implemented for all standard charsets, with up to 10x performance
On Mon, 15 Feb 2021 11:22:10 GMT, Claes Redestad wrote:
> This patch exposes a couple of intrinsics used by String to speed up ASCII
> checking and byte[] -> char[] inflation, which can be used by latin1 and
> ASCII-compatible CharsetDecoders to speed up decoding operations.
>
> - Fast-path
21 matches
Mail list logo
