RFR: 8078644: CDS needs to support JVMTI CFLH
Jiangli Zhou
jiangli.zhou at oracle.com
Fri Sep 9 18:27:14 UTC 2016
Hi Serguei,
Thanks for the review and suggestion! Fixed.
Thanks,
Jiangli
> On Sep 8, 2016, at 11:27 PM, serguei.spitsyn at oracle.com wrote:
>
> Hi Jiangli,
>
> The fix looks good.
>
> One nit:
>
> http://cr.openjdk.java.net/~jiangli/8078644/webrev.00/src/share/vm/oops/instanceKlass.hpp.frames.html <http://cr.openjdk.java.net/~jiangli/8078644/webrev.00/src/share/vm/oops/instanceKlass.hpp.frames.html>
>
> 804 #if INCLUDE_CDS && INCLUDE_JVMTI
> 805 void set_archived_class_data(JvmtiCachedClassFileData* data) {
> 806 _cached_class_file = data;
> 807 }
> 808
> 809 JvmtiCachedClassFileData * get_archived_class_data();
> 810 #endif
>
> It would be more natural to place this fragment before the line:
> 792 #else // INCLUDE_JVMTI
> so that the INCLUDE_JVMTI can be removed from the line 804.
> You used the same approach in the instanceKlass.cpp for lines 3640-3649.
>
>
> Thanks,
> Serguei
>
>
>
> On 9/6/16 17:14, 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> <https://bugs.openjdk.java.net/browse/JDK-8141341>).
>>
>> webrev:http://cr.openjdk.java.net/~jiangli/8078644/webrev.00/ <http://cr.openjdk.java.net/~jiangli/8078644/webrev.00/>
>> bug: JDK-8078644 <https://bugs.openjdk.java.net/browse/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