Re: RFR: 8299807: newStringUTF8NoRepl and getBytesUTF8NoRepl always copy arrays

2023-01-09 Thread Glavo 
On Mon, 9 Jan 2023 17:07:53 GMT, Sergey Tsypanov  wrote:

> Why don't we just call `s.isLatin1()` instead of `coder == LATIN1 && 
> isASCII(val)`?

The `isLatin1()` can only replace `coder == LATIN1`, and it is necessary to 
check whether it is ASCII.

In the following, we also need to pass the `coder` when calling `encodeUTF8`. 
Therefore, I think it is clearer to judge the `coder` directly than to call 
`isLatin1()`.

-

PR: https://git.openjdk.org/jdk/pull/11897

Re: RFR: 8299807: newStringUTF8NoRepl and getBytesUTF8NoRepl always copy arrays

2023-01-09 Thread Sergey Tsypanov 
On Mon, 9 Jan 2023 03:34:55 GMT, Glavo  wrote:

> `JavaLangAccess::newStringUTF8NoRepl` and 
> `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They 
> always copy arrays, rather than avoiding copying as much as possible as 
> javadoc says.
> 
> I ran the tier1 test without any new errors.

src/java.base/share/classes/java/lang/String.java line 927:

> 925: byte[] val = s.value();
> 926: byte coder = s.coder();
> 927: if (coder == LATIN1 && isASCII(val)) {

Why don't we just call `s.isLatin1()` instead of `coder == LATIN1 && 
isASCII(val)`?

-

PR: https://git.openjdk.org/jdk/pull/11897

Re: RFR: 8299807: newStringUTF8NoRepl and getBytesUTF8NoRepl always copy arrays

2023-01-09 Thread Glavo 
On Mon, 9 Jan 2023 03:34:55 GMT, Glavo  wrote:

> `JavaLangAccess::newStringUTF8NoRepl` and 
> `JavaLangAccess::getBytesUTF8NoRepl` are not implemented correctly. They 
> always copy arrays, rather than avoiding copying as much as possible as 
> javadoc says.
> 
> I ran the tier1 test without any new errors.

Can someone open a issue for me on JBS?

-

PR: https://git.openjdk.org/jdk/pull/11897