Hi Mandy,
Webrev updated in place: (Only System.java is modified)
http://cr.openjdk.java.net/%7Erriggs/webrev-props-cleanup-8185496/index.html
On 11/07/2018 07:19 PM, Mandy Chung wrote:
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.
ok, https://bugs.openjdk.java.net/browse/JDK-8213551
Please review when it is convenient.
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).
ok, will do
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.
Its cleaner to keep it in the jvm_initProperties function and not pollute
the general Arguments parsing code with this exception case.
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.
yep, that's next.
Thanks, Roger
Mandy
