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