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

[Jiangli Zhou]

Hi Claes,

Looks good to me. Dmitry’s suggestion of using memcmp() in this case might help a little further.

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.
>