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

[Ioi Lam]

On 6/15/15 1:55 AM, Claes Redestad wrote:
> 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.
>
When running with -Xshare:dump, we don't execute any Java code (to avoid 
having side effects in the archived classes). That may be a bit of 
paranoid, but without any overwhelming reason, I'd like to keep it that way.

To include the auto-generated classes in the archive, we could spawn a 
new JVM process to generate those classes and save them into a file. 
Then, load those classfiles into the JVM process that's running 
-Xshate:dump.

But, I think Claes' proposal is better. If we know that some 
auto-generated classes are always needed, shouldn't we pre-generate them 
at build time and include them into the jimage file? That way, they can 
be used regardless of whether CDS is used.

- Ioi


> /Claes
>
>>
>> Rémi
>>
>