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

[Ioi Lam]

Hi Claes,

The code looks good. A small nit: maybe str_equal() should be a member 
of the Flag class?

Also, if you want to avoid adding the _name_len to save on the 
footprint, how about

  inline bool str_equal(const char* s, const char* q, size_t q_len) {
     if (s[0] != q[0]) {
        return false;
     } else {
       return strncmp(s, q, q_len) == 0;
     }
}

Thanks
- Ioi

On 4/24/17 10:12 PM, 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
>
>