RFR: 8215159: Improve initial setup of system Properties
Claes Redestad
claes.redestad at oracle.com
Tue Dec 11 18:48:18 UTC 2018
Hi,
On 2018-12-11 19:08, Roger Riggs wrote:
> Hi Claes,
>
> SystemProps.java:
> - the import of Collections isn't used.
will fix before push.
>
> VM.java:
> - line 180: The savedProps doesn't need to be (and was not
> previously) unmodifiable.
> Seems safer this way though since the map at the bottom is not
> ConcurrentHashMap.
> Its not entirely clear who calls getSavedProperties().
> Would it be more efficient for savedProps to be the unmodifiable map
> and not create
> one on every call to getSavedProperties.
VM.getSavedProperties should be removed, but that requires some
coordination that is out of scope for this improvement.
There's only one caller, and they cache it in a static field. Not
wrapping VM.savedProps marginally improves speed of VM.savedProperty
which is more used during startup.
>
> VersionProps.java.template:
> - The version properties don't need to be in the savedProps map and
> could be put only in the Properties.
> (save a few cycles and entries).
Good point. I have played with code that goes even further (no need to
put any of the Raw properties in the savedProps map). We can save maybe
another 6k executed bytecode in total, but as it gets unclear what can
be found in VM.savedProperties and what can be found in the System
properties I decided against it in this patch.
Thanks!
/Claes
>
> System.java:
> - swap lines 805/806 if you decide not to put version props in the map.
> - and call VerionProps.init() after the call to createProperties().
>
> Regards, Roger
>
>
>
> On 12/11/2018 12:41 PM, Mandy Chung wrote:
>>
>>
>> On 12/10/18 1:17 PM, Claes Redestad wrote:
>>> Hi,
>>>
>>> by inverting the order in which the internal property maps are created,
>>> we avoid some classloading and get a slightly more efficient code
>>> execution profile in System.initPhase1.
>>>
>>> Webrev: http://cr.openjdk.java.net/~redestad/8215159/jdk.00/
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215159
>>>
>>
>> This change looks okay to me.
>>
>> ModuleBootstrap also removes some `jdk.module.*` private system
>> properties during
>> module system initialization but they are only set if module-related
>> command-line
>> options are set. These properties are not present in the common
>> cases. These
>> private system properties are the interface between VM and
>> libraries. There is
>> other mechanism that we can look into to replace using system
>> properties in the
>> future.
>>
>> Mandy
>
More information about the core-libs-dev
mailing list