Re: StringCoding.hasNegatives

2021-10-01 Thread Claes Redestad
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 impleme

Re: StringCoding.hasNegatives

2021-10-01 Thread Aleksey Shipilev
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. Hav

Re: StringCoding.hasNegatives

2021-10-01 Thread Brett Okken
> 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

Re: StringCoding.hasNegatives

2021-10-01 Thread Andrew Haley
On 10/1/21 1:57 PM, Brett Okken wrote: > I know java.lang.StringCoding.hasNegatives has a > HotSpotIntrinsicCandidate annotation/implementation, but is there > interest/value in a faster pure java implementation? > > Using Unsafe to read and compare 8 bytes at a time as a long is faster > than the