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

Martin Buchholz martinrb at google.com
Mon Dec 4 21:06:28 UTC 2017

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.

More information about the core-libs-dev mailing list