On 24 Sep 2015, at 00:22, Martin Buchholz <marti...@google.com> wrote:
>
> On Wed, Sep 23, 2015 at 2:41 PM, Paul Sandoz <paul.san...@oracle.com> wrote:
> On 23 Sep 2015, at 21:33, Martin Buchholz <marti...@google.com> wrote:
>>
>>
>> In Helpers:
>>
>> 121 private static String newStringUnsafe(char[] chars) {
>> 122 // If porting to a JDK where sun.misc.SharedSecrets is not
>> 123 // available, modify the code below to simply:
>> 124 // return new String(chars);
>> 125 // TODO: Can we do this more portably?
>> 126 return
>> sun.misc.SharedSecrets.getJavaLangAccess().newStringUnsafe(chars);
>> 127 }
>>
>> Yes, you can do this more portably *and* safely by not using it! :-)
>>
>> Do we really really need to use SharedSecrets? IMO this unsafe dependency
>> should be removed in the JDK patch.
>>
>> Of course, this is "just" a (relatively unimportant) performance
>> optimization.
>
> Keeping focus, i think the first question to be asked is whether for a
> particular use-case unsafe String construction is really necessary, and in
> this case i strongly suspect the answer is no.
>
>
> We're maintaining a low-level library, with great attention to performance.
> You never know if there's a user who's printing/logging bound.
>
> Anyways, you feel strongly about this, so ... they're gone! Webrevs updated.
>
Thanks! You may notice some churn in this area with Chris’s patch.
Still this does not absolve us from exploring preferably safe and more
efficient construction solutions in the future. Sorry that i sidestepped your
other important questions early on. My hope is we can improve hotspot to better
recognise that the char[] array does not escape (and in addition it is frozen
before it is assigned to the associated field in String)
Paul.
