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

[Claes Redestad]

Hi Remi,

On 06/15/2015 09:06 AM, Remi Forax wrote:
> Hi all,
>
> [ ...]
>
>>> 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
>
> While method handle support classes like these ones are generated 
> dynamically, they are stable, i.e. the code is always the same given a 
> name so it will be great if there is a way to store them in CDS to 
> improve the startup time by avoiding to generate such classes.
>
> but this can be done in a follow up patch.

I had the same suspicion. OTOH, if some generated classes are so 
commonly used that they end up in these lists maybe they should be made 
concrete (like j.l.i.BoundMethodHandle$Species_L)?

I suspect adding support for dumping generated classes this might be 
more work than it's worth in the face of optimizing away 3 small classes 
(no data to back that up, though), but the usage might grow over 
upcoming releases as more and more core libraries pick up and use them. 
Definitely something to consider, though.

/Claes

>
> Rémi
>