[10] RFR: 8179224: Cache strlen of Flag::_name

[Claes Redestad]

Hi Dmitry and Jiangli,

On 2017-04-24 20:56, Jiangli Zhou wrote:
> Hi Claes,
>
> Looks good to me.

Thanks!

>   Dmitry’s suggestion of using memcmp() in this case might help a little further.

It shouldn't hurt, at least. I've incorporated the change in place.

/Claes

>
> Thanks,
> Jiangli
>
>> On Apr 24, 2017, at 8:56 AM, Dmitry Samersoff <dmitry.samersoff at oracle.com> wrote:
>>
>> Claes,
>>
>> Nit:
>>
>> globals.cpp:870 - you can use memcmp() here.
>>
>> Looks good to me.
>>
>> -Dmitry
>>
>>
>> On 2017-04-24 17:12, Claes Redestad wrote:
>>> Hi,
>>>
>>> startup profiling shows we're spending a surprising amount of cycles
>>> checking flag constraints and value ranges due to scanning the list of
>>> flags once for every range/constraint, which means we do more than 300k
>>> calls to Flag::find_flag.  A complete and elegant fix to this should
>>> consider rewriting the algorithm, e.g., emitting lists of flags, ranges
>>> and constraints in lexical order to allow for linear scans, or even
>>> better inline the range and constraint structs into the Flag struct[1].
>>>
>>> However, it turns out most (>80%) of the measured overhead at startup
>>> can be avoided by simply caching the result of doing
>>> strlen(Flag::_name), thus I propose this partial (and temporary?) fix:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179224
>>> Webrev: http://cr.openjdk.java.net/~redestad/8179224/hotspot.01/
>>>
>>> Testing: various hotspot command line tests locally and in rbt
>>>
>>> Thanks!
>>>
>>> /Claes
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8178991
>>>
>>>
>>
>> -- 
>> Dmitry Samersoff
>> Oracle Java development team, Saint Petersburg, Russia
>> * I would love to change the world, but they won't give me the sources.
>>