StringCoding.hasNegatives

Claes Redestad claes.redestad at oracle.com
Fri Oct 1 16:02:46 UTC 2021



On 2021-10-01 16:53, Aleksey Shipilev wrote:
> On 10/1/21 4:46 PM, Brett Okken wrote:
>>> The current pure Java implementation does two things: it provides a 
>>> fallback
>>> for pure-interpreter JVMs and it provides the reader with a simple 
>>> implementation.
>>> I'm not at all sure we'd want a complex implementation.
>>
>> I thought this might be the case.
>>
>>> Having said that, if I were looking at a faster pure Java version of
>>> this logic, I'd look at MethodHandles.byteArrayViewVarHandle().
>>
>> I considered that, but had 2 concerns:
>> 1. creating potential dependency/initialization order issues
>> 2. creating/managing a constant VarHandle that would never be used
>> with normal compiler behavior
> 
> Also, interpreter-only VMs are likely to be pessimized by 
> Var/MethodHandles, as they would not be able to fold a lot of code (e.g. 
> checks) on the hotpaths. I have seen this after SHA-2 was rewritten to 
> use byteViews (that one was done for simplicity, rather than directly 
> for performance, I think).

Guilty as charged! I did experiment with some slightly wonky ways to
soften the blow to interpreter performance[1], but ultimately opted to
maximize simplicity.

> 
> Optimizing this does not seem worth it, in my opinion. The only reason 
> to do this would be showing that it improves the interpreter performance 
> so much it improves startup until compilers are coming up with the 
> optimized code.
> 

I agree with this assessment.

Thanks!
/Claes

[1] 
https://github.com/openjdk/jdk/pull/1855/commits/4b4fb2dd078eb71bd41ad3cf61b87a93575171a0


More information about the core-libs-dev mailing list