RFR (S): 8213439: Run class initialization for boot loader classes with registered subgraph archiving entry field during CDS dump time

[David Holmes]

Hi Jiangli,

Messing with the established initialization order still rings alarm 
bells for me. Can you generate the normal class initialization list for 
VM startup, and one for a CDS dump, so that we can see how they differ. 
It would very easy for subtle initialization bugs to creep in here. 
(Even with the existing use of Java code during dump time.)

Thanks,
David

On 8/11/2018 10:45 AM, Jiangli Zhou wrote:
> Please review following webrev that explicitly runs class initialization 
> for classes (for boot loader only) with registered subgraph archiving 
> entry field(s) during CDS dump time.
> 
> At CDS dump time, some of the loaded classes are initialized due to 
> execution of java code. Currently there are 279 classes are initialized 
> at dump time. The rest of the loaded classes are not initialized. 
> Running class initialization for the boot classes with registered 
> subgraph archiving entry field(s) will allow those static fields (and 
> their directly/indirectly referenced objects) being populated at CDS 
> dump time and archived. The Long$LongCache (planned for JDK-8213033 by 
> Claes, thanks!) is such an example.
> 
>    webrev: http://cr.openjdk.java.net/~jiangli/8213439/webrev.00/
> 
>    RFE: https://bugs.openjdk.java.net/browse/JDK-8213439
> 
> The initialization of a class is triggered explicitly when processing 
> the subgraph entry fields at dump time. For any class that's already 
> initialized at this point, it's essentially a nop. That's the case for 
> current existing subgraph entries.
> 
> Tested with tier1-tier3. Thanks David and Ioi's for discussions in the 
> bug report.
> 
> Thanks,
> 
> Jiangli
>