RFR: 8176188: jdk/internal/misc/JavaLangAccess/NewUnsafeString.java failing since 9-b93

[Martin Buchholz]

I'm rather sad about what happened to our non-copying String constructions
for trusted code.  This is a performance regression with the change in
String representation that should have blocked that change IMO.  I think we
should have a plan for moving in the opposite direction.  I don't think we
can implement something as ambitious as Rust's ownership tracking, so have
to restrict ourselves to trusted code.  The use case that keeps coming up
is constructing zip entry names, which are much more likely to be pure
ASCII than their file contents.

I don't have a good design for how one could do that, and who the trusted
set of callers is (at least java.base, not java.lang), but I think we
should set a direction.

On Sun, Dec 3, 2017 at 11:53 AM, Claes Redestad <claes.redestad at oracle.com>
wrote:

> Hi,
>
> the compact strings JEP changed semantics of the package-private
> String(char[], boolean)
> constructor to do the same as the public String(char[]) constructor.
>
> Previously the former was used in trusted, internal code to avoid copying
> the given char[],
> but since the char[] now has to be converted to a byte[] that optimization
> is no longer
> possible via this method[1], and tests that checked that the returned
> string shared the
> given char[] naturally stopped working.
>
> To fix this bug I propose the following clean-up:
> - change all uses of JavaLangAccess.newUnsafeString(char[]) to new
> String(char[])
> - remove the package-private String(char[], boolean) constructor
> - remove the newUnsafeString from JavaLangAccess
> - remove the now unnecessary NewUnsafeString test
>
> Patch: http://cr.openjdk.java.net/~redestad/8176188/open.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8176188
>
> Thanks!
>
> /Claes
>
> [1] For some of the usages here we could improve somewhat by exposingthe
> String(byte[], byte)
> constructor, but I think that's out of scope here and I think we'd best
> avoid leaking the
> coder byte implementation detail outside of java.lang.
>