RFR: 8179224: Cache strlen of Flag::_name
jiangli.zhou at oracle.com
Mon Apr 24 18:56:48 UTC 2017
Looks good to me. Dmitry’s suggestion of using memcmp() in this case might help a little further.
> On Apr 24, 2017, at 8:56 AM, Dmitry Samersoff <dmitry.samersoff at oracle.com> wrote:
> globals.cpp:870 - you can use memcmp() here.
> Looks good to me.
> On 2017-04-24 17:12, Claes Redestad wrote:
>> 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.
>> 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
>>  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.
More information about the hotspot-runtime-dev