RFR : 8013528 : (XS) Provide SharedSecrets access to String(char[], boolean) constructor
Mike Duigou
mike.duigou at oracle.com
Fri May 3 18:00:50 UTC 2013
On Apr 30 2013, at 23:41 , Peter Levart wrote:
> Hi Mike,
>
> Some comments about the test...
>
> 40 String benchmark = "exemplar";
> 41 String constructorCopy = new String(benchmark);
> 42 String jlaCopy = jla.newStringUnsafe(benchmark.toCharArray());
> 43
> 44 if (constructorCopy == constructorCopy) {
> 45 throw new Error("should be different instances");
> 46 }
> Wouldn't this always throw error? You really wanted to test benchmark == constructorCopy, right?
Argh, yes. I forgot a hg qrefresh before generating the webrev. This was corrected in my local copy.
> To check whether the jlaCopy is really taking the given char array by reference, a test could also do something "illegal" like:
>
>
> char[] array = benchmark.toCharArray();
> String jlaCopy = jla.newStringUnsafe(array);
> array[0] = "X"; // ouch!
> String constructorCopy = new String(array);
>
> if (!constructorCopy.equals(jlaCopy)) { ... }
>
> Regards, Peter
>
I have added an "evil" test to check exactly that.
I'm pleased to be able to include you an official reviewer. :-)
Thanks,
Mike
>
>
>
> 2013/5/1 Mike Duigou <mike.duigou at oracle.com>
> Hello all;
>
> Since this code will be introduced without any usages I decided it was critical to make a stand alone unit test. I've updated the webrev:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8013528/1/webrev/
>
> The webrev mistakes my hg copy for a rename... Ignore that. Capturing the provenance of the test file probably isn't critical since the file is repurposed for a different test, but I prefer to have the origin tracked rather than use a non-vcs copy.
>
> I also made the other changes suggested by reviewers.
>
> Thanks
>
> Mike
>
> On Apr 29 2013, at 21:30 , Mike Duigou wrote:
>
> > Hello all;
> >
> > This change originated as part of JDK-8006627 (which was also previously split into JDK-8007398 as well). It adds an internal mechanism for performance sensitive usages to create a string from a provided character array without copying that array. This saves both in the allocation (and subsequent GC) as well as the copying of the characters. There are a few places in the JDK that return Strings which can benefit from this change.
> >
> > http://cr.openjdk.java.net/~mduigou/JDK-8013528/0/webrev/
> >
> > Fear not, JDK-8006627 and JDK-8007398 will be revisited... For now it would be to get this change in to allow other potential users to move forward with their changes.
> >
> > Mike
>
>
More information about the core-libs-dev
mailing list