Hi Roger
On 11/6/18 8: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
2) Two tests for properties are combined into a more complete test
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-props-cleanup-8185496/
This is a good cleanup. Some comments:
Is "user.timezone" system property not set by default? Before the
change, System.getProperty("user.timezone") always returns non-null.
With this patch, if it returns null, it may need a CSR for this
behavioral change.
System.java
804 initProperties(props);
805 System.props = props;
806 VersionProps.init();
This seems worth refactoring of existing code.
initProperties(props) and VersionProps.init() are called in initPhase1.
I think VersionProps.init can be called right after initProperties(props)
in initPhase1. So it'd be cleaner to have a java method to call
initProperties(props) and add the version-related system properties
to the given props (i.e. VersionProps.init could take Properties object).
jvm.cpp
The other place to filter the property is Arguments::add_property
or maybe in Arguments::parse_argument. The runtime team can advise
where is the preferred place.
As you mentioned the future cleanup, the VM is using system properties
as the internal interface with the library code and in some cases the
library code removes those system properties after startup
(VM.saveAndRemoveProperties). As we discussed, one approach would be to
define a native JVM interface to fetch the values in a batch but we have
to measure the performance to determine if this is better.
Mandy
