RFR (M) 8140802 - Clean up and refactor of class loading code for CDS

Ioi Lam ioi.lam at oracle.com
Mon Nov 2 18:57:43 UTC 2015



On 10/30/15 1:31 PM, Coleen Phillimore wrote:
>
>
> On 10/30/15 4:18 PM, Karen Kinnear wrote:
>> Coleen,
>>
>> Question for you below please ...
>>> On Oct 30, 2015, at 3:44 PM, Coleen Phillimore 
>>> <coleen.phillimore at oracle.com> wrote:
>>>
>>>
>>> Hi Ioi,
>>> This is a manageable code change.
>>>
>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classListParser.hpp.html 
>>>
>>>
>>> You forward declare Klass* but don't use it in this header file.
>>> Also can you add a comment to #endif  to say what it's endifing. ie. 
>>> // SHARE_VM_MEMORY_CLASSLISTPARSER_HPP
>>>
>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/classLoaderExt.cpp.html 
>>>
>>>
>>>   33   TempNewSymbol class_name_symbol = 
>>> SymbolTable::new_permanent_symbol(parser->current_class_name(), 
>>> THREAD);
>>>
>>> This doesn't make sense.   If you want a permanent symbol, it 
>>> doesn't need to get un-reference counted with the TempNewSymbol 
>>> destructor.
>> Thank you for chiming in on this one - I wanted your opinion here. 
>> (this code used to be in MetaspaceShared::
>> preload_and_dump and I think was wrong there as well).
>> My understanding is that it is a TempNewSymbol that he wants, so he 
>> should call SymbolTable::new_symbol.
>> The code creates a (temporary) symbol for the name, and then calls 
>> SystemDictionary::resolve_or_null, which if it
>> succeeds will walk through the classFileParser which will create a 
>> permanent symbol for the class name,
>> via the symbol_alloc_batch handling. That would be consistent with 
>> the TempNewSymbol call in
>> SystemDictionary::resolve_or_null as well as in parse_stream - all 
>> places dealing with the class name
>> before doing classfile parsing.
>>
>> Does that make sense?
>
> Yes, this makes sense.  The symbol shouldn't be permanent.   Ioi can 
> test this by putting a strange long name in the classlist file and 
> make sure it doesn't make it out to the shared archive, since I think 
> -Xshare:dump cleans out the SymbolTable before dumping.
>
After changing to use new_symbol instead of new_permanent_symbol, I ran 
-Xshare:dump:

$ java -Xshare:dump
Preload Warning: Cannot find sun/text/normalizer/UnicodeMatcher
...
total   :  13063134 [100.0% of total] out of  27385856 bytes [47.7% used]

$ strings images/jdk/lib/i386/hotspot/classes.jsa | grep 
sun/text/normalizer/UnicodeMatcher
sun/text/normalizer/UnicodeMatcher

So the unused symbols are not removed. Anyway, I have filed a separate 
issue for this: https://bugs.openjdk.java.net/browse/JDK-8141207

Thanks
- Ioi


> Coleen
>>
>> thanks,
>> Karen
>>
>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/hotspot/src/share/vm/classfile/systemDictionary.cpp.udiff.html 
>>>
>>>
>>> +    // Make sure we have an entry in the SystemDictionary on success
>>>
>>>
>>> This assert code is a copy of some code elsewhere.  Can you make it 
>>> a function that they boh can call?
>>> Can you also comment the raw #endif's to what they're endifing?
>>>
>>> Otherwise, this looks okay.
>>>
>>> Coleen
>>>
>>>
>>> On 10/30/15 1:00 PM, Ioi Lam wrote:
>>>> Please review the following fix:
>>>>
>>>> http://cr.openjdk.java.net/~iklam/8140802-cds-refactoring.v01/
>>>>
>>>> Bug: Clean up and refactor of class loading code for CDS
>>>>
>>>>     https://bugs.openjdk.java.net/browse/JDK-8140802
>>>>
>>>> Summary of fix:
>>>>
>>>>     We need to clean up and refactor the class loading code in order
>>>>     to support CDS in JDK9
>>>>
>>>>     [1] Remove code that has been made obsolete by the module changes
>>>>         (such as supporting code used for meta-index file)
>>>>     [2] Add new whitebox API to be used by CDS-related tests.
>>>>     [3] Refactor the parsing of classlist files for future 
>>>> enhancements.
>>>>     [4] Add new APIs in the class loading code to support Oracle 
>>>> CDS enhancements.
>>>>
>>>> Tests:
>>>>
>>>>     JPRT
>>>>     RBT - with same set of tests as hs-rt nightly
>>>>
>>>> Thanks
>>>> - Ioi
>




More information about the core-libs-dev mailing list