RFR: 8078644: CDS needs to support JVMTI CFLH

Jiangli Zhou jiangli.zhou at oracle.com
Fri Sep 9 17:26:04 UTC 2016


Hi Ioi,

Thanks for the review!

Jiangli

> On Sep 8, 2016, at 11:02 PM, Ioi Lam <ioi.lam at oracle.com> wrote:
> 
> Hi Jiangli,
> 
> The code looks good. Thank you so much for doing this important work!
> 
> - Ioi
> 
> On 9/6/16 5:14 PM, Jiangli Zhou wrote:
>> Hi,
>> 
>> Please review the following change thats support JVMTI class_file_load_hook(CFLH) during initial loading of shared classes. The webrev also removes the temporary workaround that disables CDS when JVMTI CFLH is required (JDK-8141341 <https://bugs.openjdk.java.net/browse/JDK-8141341>).
>> 
>> 	webrev:http://cr.openjdk.java.net/~jiangli/8078644/webrev.00/
>>         bug: JDK-8078644 <https://bugs.openjdk.java.net/browse/JDK-8078644>
>> 
>> Class file data is needed when posting CFLH. For shared classes, the class file data are now archived at dump time. That avoids re-reading the class file data from the JAR file or reconstituting the data at runtime, which would add class loading overhead for shared classes.
>> 
>> To minimize the runtime memory overhead, the archived class file data are stored in a separate shared space, called ‘optional data space’ (od).  The ‘od’ space a new region in the archive. It does not increase runtime memory usage when JvmtiExport::should_post_class_file_load_hook() is false. The memory contains the archived class file data is only paged in when the VM needs to post CFLH.  The ‘od’ space can be shared by different processes.
>> 
>> When loading shared class at runtime, we now call JvmtiExport::post_class_file_load_hook() with the archive class file data if needed. If JVMTI agent modifies the class, new InstanceKlass is created using the modified class data and the archived class is ignored.
>> 
>> Tested with JPRT, CDS tests and QA tests.
>> 
>> Thanks,
>> Jiangli
> 



More information about the hotspot-runtime-dev mailing list