RFR [8u60]: 8081590: The CDS classlist needs to be updated for 8u60

[Claes Redestad]

On 06/15/2015 02:22 AM, David Holmes wrote:
> Hi Claes,
>
> On 13/06/2015 3:23 AM, Claes Redestad wrote:
>> On 06/12/2015 06:54 PM, Jiangli Zhou wrote:
>>> Hi Claes,
>>>
>>> On Jun 12, 2015, at 3:43 AM, Claes Redestad
>>> <claes.redestad at oracle.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I've been trying to find out why the previous refresh sorted classes
>>>> in package order. This seems to
>>>> run counter to the intent of the classlist as a source for the
>>>> jarreordering optimization and the only
>>>> documentation I've been able to find in the JDK sources for classlist
>>>> generation suggests concatenating
>>>> in the order of class loading is the original intent[1]. Since we see
>>>> better behavior in general with the
>>>> refreshed classlists, I'd prefer not sorting in package order, but I
>>>> still think a more thorough refresh of
>>>> the documentation and tools for JDK9 is in order (I've already filed
>>>> RFEs to cover some of this).
>>> I agree with that.
>>
>> Good.
>
> So is the current list sorted in actual class loading order (for some 
> application) ? 

Yes.

> That seems reasonable.
>

I think so, too. :-)

>
>>>> Anyhow, below I've attached a diff of current vs refreshed classlist
>>>> for linux after sorting the suggested
>>>> class list in package order.
>>>>
>>>> In summary, most of the added classes seem to be related to
>>>> j.l.invoke and other Lambda-related
>>>> classes, including asm. This seems reasonable to me due to the uptake
>>>> of lambdas, streams etc in the
>>>> JDK since 8-b117. Also numerous changes in client-libs, anonymous
>>>> classes that have shifted around
>>>> (adding in or removing anonymous classes in source will shift things
>>>> up or down).
>>> One thing we need to make sure is to not include dynamically generated
>>> Lambda classes in the list. My quick scan of the following diff didn’t
>>> find any. So the change looks ok to me.
>>
>> Thanks!
>>
>> I guess such cases would simply be ignored (with a warning) when dumping
>> the shared archive. While avoiding warnings is intrinsically good, I
>> can't see that it'd create any real issues, would it?
>>
>> On a closer inspection I noticed that 3 such warnings are emitted during
>> -Xshare:dump:
>>
>> java/lang/invoke/BoundMethodHandle$Species_L3
>> java/lang/invoke/BoundMethodHandle$Species_L4
>> java/lang/invoke/BoundMethodHandle$Species_LL
>>
>> These are lazily generated by BoundMethodHandle, so I've removed these
>> from the lists:
>>
>> http://cr.openjdk.java.net/~redestad/8081590/webrev.01
>
> Inclusion of the classes for the new API's seem most appropriate, as 
> well as deleting non-existent classes. It is good to see no warning 
> with the build or with -Xshare:dump in that regard.

Thanks!

/Claes

>
> Thanks,
> David
>
>
>> /Claes
>>>
>>> Thanks,
>>> Jiangli
>>