RFR 8185496: Improve performance of system properties initialization in initPhase1

[Roger Riggs]

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