RFR: 8278325: excluded class should not be checked again for exclusion

Yumin Qi minqi at openjdk.java.net
Thu Jan 27 02:14:36 UTC 2022


On Thu, 27 Jan 2022 01:35:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Hi, Please review
>> 
>>   When LambdaFormInvoker regenerate lambda form holder class, the old class with the same name already loaded and is marked for excluded for dump. This class should not be checked against exclusion, or it will output unexpected warning like:
>> [0.394s][warning][cds] Skipping java/lang/invoke/BoundMethodHandle$Species_J: Unsupported location
>> [0.394s][warning][cds] Skipping java/lang/invoke/BoundMethodHandle$Species_JL: Unsupported location
>> [0.394s][warning][cds] Skipping java/lang/invoke/BoundMethodHandle$Species_FL: Unsupported location
>> [0.394s][warning][cds] Skipping java/lang/invoke/BoundMethodHandle$Species_F: Unsupported location
>>   The fix changed the order for checking exclusion of a class --- only check for those that have not been set for exclusion. Original function DumpTimeClassInfo::is_excluded in fact is checking three conditions in logical OR, it does not tell which reason for exclusion. In this fix, we need check the exact reason which is set for _excluded. Original is_excluded is renamed to should_be_excluded.
>> 
>> Tests: tier1,tier4 (in testing)
>> 
>> Thanks
>> Yumin
>
> test/hotspot/jtreg/runtime/cds/appcds/TestDumpClassListSource.java line 122:
> 
>> 120: 
>> 121:         output.shouldHaveExitValue(0)
>> 122:               .shouldContain(warningMessage);
> 
> Why would the above process generate the "Skipping java/lang/invoke/BoundMethodHandle$Species_" message?

This is dynamic dump, the problem is filed against static dump. When do dynamic dump we did not have those SPECIES_RESOLVE in classlist like static dump. They are not regenerated in fact.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7225


More information about the hotspot-runtime-dev mailing list