RFR: 8196334: Optimize UUID#fromString

[Claes Redestad]

Hi Ivan,

I've considered trying it out, but it gets complicated as we don't want
to penalize -XX:-UseCompactStrings.

I think adding special methods for UUID inside StringLatin1 is a step
in the wrong direction, but maybe there's something more generic we can
consider. However, short of adding String.value()+coder() access via
JavaLangAccess I'm not sure there's anything that'd net us any
significant gain. And I don't think it's worth it to open up that
particular can of worms right now just for this.

/Claes

On 2020-02-28 20:51, Ivan Gerasimov wrote:
> Hi Claes and Andriy!
> 
> It looks good overall.
> 
> I wonder if it'll be even faster if the fast path were implemented in 
> StringLatin1 (for compact strings only) and was called via 
> SharedSecrets/JavaLangAccess?
> 
> Then, you could operate directly on bytes and avoid dealing with longs.
> 
> With kind regards,
> 
> Ivan
> 
> 
> On 2/28/20 6:22 AM, Claes Redestad wrote:
>> Hi all,
>>
>> please review this patch to optimize UUID#fromString.
>>
>> Jon Chambers originally proposed a patch that used a strict parser to
>> get a similar speed-up, but I failed to adapt it in a way that
>> could fall back to the less strict behavior while maintaining a
>> reasonable speed-up in the fast-path case. Sorry, Jon!
>>
>> The patch proposed here was recently contributed by Andriy Plokhotnyuk
>> (OCA signed), and manages to get more than a 3x speed-up on the new
>> fromString microbenchmark, while falling back gently to the current,
>> less strict implementation if ever needed. I've done some light edits,
>> and added a simple microbenchmark.
>>
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8196334
>> Webrev: http://cr.openjdk.java.net/~redestad/8196334/open.00/
>>
>> Testing: tier1-3
>>
>> Thanks!
>>
>> /Claes
>