RFR 8185496: Improve performance of system properties initialization in initPhase1

David Holmes david.holmes at oracle.com
Wed Nov 7 07:11:00 UTC 2018


Hi Roger,

Thanks for expanding on the issue. Hopefully in the future this can be 
handled in a more direct way.

Thanks,
David

On 7/11/2018 8:13 AM, Roger Riggs wrote:
> 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
>>>
>>>
>>>
> 


More information about the core-libs-dev mailing list