RFR(S) 8189140 - SystemDictionaryShared::initialize() should be renamed to be more meaningful
Ioi Lam
ioi.lam at oracle.com
Tue May 15 21:47:47 UTC 2018
I've updated the webrev:
http://cr.openjdk.java.net/~iklam/jdk11/8189140-rename-system-dict-shared-initialize.v02/
1. Added JavaCalls::new_instance so we can avoid all the boiler plate
code for allocating
the instance andinvoking the constructor.
JavaCalls::new_instance calls InstanceKlass->initialize. This is just a
quick op after
the class is already initialized. Also, JavaCalls::call_static also
internally call
into InstanceKlass->initialize, so I am just following the existing
pattern as Coleen
mentioned below.
Doing the initialization on demand also means for cases where JAR
manifest is not used
(all code is loaded from the system image or directories), we get
faster start-up.
2. I also took the time to removed a bunch of "// One oop argument"
comments which
probably meant something to the person who wrote it, but seems
useless to everyone
else.
3. As Calvin suggested, I removed the File_klass and also
ParseUtil_klass from
the system dictionary since they are not used anywhere. This
hopefully improves start-up
by a little bit, since these 2 classes are no longer resolved at
start-up.
(BTW, I changed the RFR subject line from XS to S due to the extend of
change :-)
Thanks
- Ioi
On 5/15/18 2:00 PM, coleen.phillimore at oracle.com wrote:
>
> http://cr.openjdk.java.net/~iklam/jdk11/8189140-rename-system-dict-shared-initialize.v01/src/hotspot/share/classfile/systemDictionaryShared.cpp.udiff.html
>
>
> This looks good. This is a pattern that's used in other places, and
> it would be better to not initialize these at startup in thread.cpp.
>
> Coleen
>
> On 5/15/18 2:07 AM, Ioi Lam wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8189140
>> http://cr.openjdk.java.net/~iklam/jdk11/8189140-rename-system-dict-shared-initialize.v01/
>>
>>
>> Summary:
>>
>> 1. Removed the forced initialization of a few classes used by AppCDS
>> at JVM start-up.
>> Instead, initialize these class on demand by calling
>> InstanceKlass::initialize, which
>> is a quick no-op if the class is already initialized.
>>
>> 2. The only initialization left is that of a global lock. So I
>> renamed the function
>> to SystemDictionaryShared::initialize_locks().
>>
>> 3. I moved the call of this function from
>> SystemDictionary::compute_java_loaders() to
>> SystemDictionary::initialize() where it seems to fit.
>>
>> Testing with hs-tiers 1 and 2.
>>
>> Thanks
>> - Ioi
>
More information about the hotspot-runtime-dev
mailing list