RFR(S) 8189140 - SystemDictionaryShared::initialize() should be renamed to be more meaningful
ioi.lam at oracle.com
Tue May 15 21:47:47 UTC 2018
I've updated the webrev:
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
into InstanceKlass->initialize, so I am just following the existing
pattern as Coleen
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
2. I also took the time to removed a bunch of "// One oop argument"
probably meant something to the person who wrote it, but seems
useless to everyone
3. As Calvin suggested, I removed the File_klass and also
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
(BTW, I changed the RFR subject line from XS to S due to the extend of
On 5/15/18 2:00 PM, coleen.phillimore at oracle.com wrote:
> 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.
> On 5/15/18 2:07 AM, Ioi Lam wrote:
>> 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.
>> - Ioi
More information about the hotspot-runtime-dev