RFR 8185496: Improve performance of system properties initialization in initPhase1

[Roger Riggs]

Hi David,

On 11/06/2018 04:52 PM, David Holmes wrote:
> Hi Roger,
>
> On 7/11/2018 2:17 AM, Roger Riggs wrote:
>> While working to reduce startup time initializing properties, a pair 
>> of improvements are proposed.
>>
>> 8185496: Improve performance of system properties initialization in 
>> initPhase1 [1]
>> 8213424: VersionProps duplicate initialization [2]
>>
>> 1) The overhead of providing default values in native is reduced by 
>> applying the defaults
>>      when first used and leaving the properties undefined unless 
>> there is
>>      an OS supplied value or a -D command line argument
>
> Looking at the hotspot change for setting sun.nio.MaxDirectMemorySize 
> I don't really understand the change. In the current code we will 
> always set the property even if the value -1 means it is "unset". Your 
> change wants to exclude it completely in the default case as an 
> optimisation, yet to do that you have to perform far more work in the 
> VM examining every key to see if we need to skip a -D set value. That 
> seems counter-productive on the surface. What is the actual 
> performance change here?
The goal is to not have default values assigned in native so they can be 
handled at the same point where a decision is made in 
VM.getSavedProperties.
If  the property has any value, it has to create the string and invoke 
Properties.put which is a bunch more instructions than a few strcmp's in 
native. (though it is proportional to the number of properties.)
And it would cleaner still if the MaxDirectMemorySize wasn't passed as a 
property but that's the
current implementation mechanism. Further cleanup is possible.

The ignoring of a -D has to be handled somewhere, and it is more 
efficient to do it early.
In retrospect, I would much have preferred that 
sun.nio.maxDirectMemorySize had just be left as a normal -D property and 
left all the clever parsing to the java code.  (But I wasn't involved in 
that).

I have a future change to replace the Property.put upcalls, but just 
dropping any unnecessary properties is a small step.

Thanks, Roger

>
> Thanks,
> David
>
>> 2) Two tests for properties are combined into a more complete test
>>
>> webrev:
>>
>> http://cr.openjdk.java.net/~rriggs/webrev-props-cleanup-8185496/
>>
>> Issues:
>> [1] https://bugs.openjdk.java.net/browse/JDK-8185496
>> [2] https://bugs.openjdk.java.net/browse/JDK-8213424
>>
>> Thanks for any comments and suggestions, Roger
>>
>>
>>