RFR 8185496: Improve performance of system properties initialization in initPhase1
Mandy Chung
mandy.chung at oracle.com
Fri Nov 9 17:15:55 UTC 2018
On 11/9/18 7:25 AM, Roger Riggs wrote:
> Hi Mandy
>
> On 11/08/2018 04:55 PM, Mandy Chung wrote:
>> On 11/8/18 7:41 AM, Roger Riggs wrote:
>>>
>>> Webrev updated in place: (Only System.java is modified)
>>>
>>> http://cr.openjdk.java.net/%7Erriggs/webrev-props-cleanup-8185496/index.html
>>
>> Just notice this...
>>
>> I wonder if System.setProperties(null) should call
>> VM.saveAndRemoveProperties(props) to be consistent. It's an existing
>> issue. You may consider refactoring and adding initSystemProperties
>> method that will be called from initPhase1 and setProperties.
>
> The purpose of VM.savedProperties is to ensure that the initial
> properties are not mutable.
> The AndRemove is an adhoc way to hide some properties that don't need
> to be seen by applications.
> Allowing the former set to be changed by setProperties() would break
> that intention.
> I'm not aware of any problems with the current implementation of
> (setProperties)
> and so would leave it alone at least for now.
>
> Further, System.setProperties() should be deprecated (probably for
> removal) since it
> gives the impression of being able to reset all the properties. But
> many property values
> are only used for initialization and are read or cached on first use
> and not read again
> because changing them has no effect or can cause unexpected behaviors.
>
I agree we should not do more on System.setProperties. Your patch is
good to go.
I also support to deprecate System::setProperties while we should
collect some data
and understand how it is used in existing libraries.
Mandy
More information about the hotspot-runtime-dev
mailing list