String.lastIndexOf confused by unpaired trailing surrogate

Ulf Zibis Ulf.Zibis at gmx.de
Mon Mar 22 14:45:32 UTC 2010


Am 21.03.2010 18:38, schrieb Martin Buchholz:
> On Sun, Mar 21, 2010 at 06:35, Ulf Zibis<Ulf.Zibis at gmx.de>  wrote:
>    
>>>        
>>>> On Sun, Mar 21, 2010 at 03:24, Ulf Zibis<Ulf.Zibis at gmx.de>    wrote:
>>>>          
>>>>> Am 21.03.2010 09:05, schrieb Martin Buchholz:
>>>>>            
>>>>>> On Sat, Mar 20, 2010 at 15:50, Ulf Zibis<Ulf.Zibis at gmx.de>      wrote:
>>>>>>              
>>>>> I think, we should not define a distinct method for this once-used
>>>>> 3-liner:
>>>>>              for (; i<    max-1; i++)
>>>>>                  if (v[i] == high&&    v[i+1] == low)
>>>>>                          return i - offset;
>>>>>
>>>>> HotSpots resources should not be over-stressed to inline such things,
>>>>> having
>>>>> more reserves for more important things.
>>>>>            
>>>> On the contrary -
>>>> normally the above code snippet will rarely be executed,
>>>> and so will normally not be inlined into the caller,
>>>> which makes it easier for hotspot to inline
>>>> the caller into its caller.  Separate cold code into
>>>> separate methods.
>>>>          
>>> Thanks, I got the idea.
>>>
>>> But Isn't the push-call-pop-return overhead comparable with those 3 lines
>>> here, not to forget the repeated cache-3-values-once-more?
>>>        
> Even if I'm wrong, and this cold code is actually hot,
> I don't think there will be a big performance loss.
> The method call is outside the loop.
>    

What about at least reusing the cached values from calling method via 
indexOfSupplementary(ch, fromIndex, value, offset, max - 1) ?

>    
>> And additionally the slow rarely used branch would stay in stone, even if
>> after some time, the inline threshhold becomes reached, as JIT, AFAIK, can't
>> count the frequency of compiled code usage.
>>      
> It's certainly the intent that we will have multiple levels of
> compilation ("tiered compilation") and profiling would be
> enabled on at least some compiled code.
>    

That's an interesting option.

-Ulf





More information about the core-libs-dev mailing list