RFR(S) 8062591: SPARC PICL causes significantly longer startup times

[Igor Veresov]

You’re right, thanks for noticing that.

Webrev: http://cr.openjdk.java.net/~iveresov/8062591/webrev.01

igor

On Nov 3, 2014, at 11:47 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:

> Next check should use != 0 (since we can use 31st bit):
> 
> (features & sparc64_family_m) > 0
> 
> Otherwise it looks good.
> 
> Thanks,
> Vladimir
> 
> On 11/3/14 1:03 PM, Igor Veresov wrote:
>> Querying cache line sizes using PICL was noticed to take a lot of time mostly because of the depth-first search in a big string-keyed tree.
>> I did the following optimizations that take care of the regression:
>> - Combined L1 and L2 traversals in a single pass.
>> - Based on the observation that the CPU-related part of the tree is closer to the side the traversal starts on, and the records about CPUs are all siblings we can stop the traversal once we’ve seen all the CPUs (os::processor_count()), leaving a significant part of the tree untouched.
>> - Avoid double traversal on Fujitsu boxes, just look once for the “core” class.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8062591
>> Webrev: http://cr.openjdk.java.net/~iveresov/8062591/webrev.00
>> 
>> igor
>>