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
