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

[David Holmes]

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) ? That seems reasonable.


>>> 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,
David


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