RFR 8185496: Improve performance of system properties initialization in initPhase1
Roger.Riggs at oracle.com
Thu Nov 8 15:41:15 UTC 2018
Webrev updated in place: (Only System.java is modified)
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 
>> 8213424: VersionProps duplicate initialization 
>> 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
> 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.
Please review when it is convenient.
> 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
> 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.
More information about the core-libs-dev