RFR 8185496: Improve performance of system properties initialization in initPhase1

[Mandy Chung]

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