RFR: jsr166 openjdk9 integration

[Paul Sandoz]

On 24 Sep 2015, at 00:22, Martin Buchholz <martinrb at google.com> wrote:
> 
> On Wed, Sep 23, 2015 at 2:41 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> On 23 Sep 2015, at 21:33, Martin Buchholz <martinrb at 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.