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