RFR(S): 8203664: JFR start failure after AppCDS archive created with JFR StartFlightRecording

Calvin Cheung calvin.cheung at oracle.com
Mon Jun 25 17:15:48 UTC 2018


After some off-list discussions, I've modified the change to disable JFR 
and output a warning message during CDS dump time if JFR is specified.

webrev: http://cr.openjdk.java.net/~ccheung/8203664/webrev.01/

warning message:
Java HotSpot(TM) 64-Bit Server VM warning: JFR will be disabled during 
CDS dumping

The change passed hs-tier[1,2,3] testing.

thanks,
Calvin

On 6/20/18, 11:18 AM, Calvin Cheung wrote:
>
> Corrected the bug id in the subject and also the link to webrev:
>
> http://cr.openjdk.java.net/~ccheung/8203664/webrev.00/
>
> (Note: 8203*6*64 instead of 8203*3*64)
>
> thanks,
> Calvin
>
> On 6/20/2018 11:04 AM, Calvin Cheung wrote:
>> bug: https://bugs.openjdk.java.net/browse/JDK-8203664
>>
>> webrev: http://cr.openjdk.java.net/~ccheung/8203364/webrev.00/
>>
>> The bug is due to some classes are being redefined during JFR 
>> startup. The proposed change is to handle redefined classes better 
>> during dump time.
>>
>> Summary of changes:
>>
>> klassFactory.cpp:
>>
>>     Only do the following assert if a class hasn't been redefined:
>>
>>     244       assert(cached_class_file == NULL, "Sanity");
>>
>> classLoader.cpp:
>>
>>     include JFR classes which are loaded via 'JVM_DefineClass'
>>
>> dictionary.cpp:
>>
>>     during dumping, exclude classes which have been redefined.
>>
>>     Only very few classes are being redefined with JFR enabled during 
>> dumping:
>>
>>     java/lang/Throwable
>>     java/net/SocketOutputStream
>>     java/net/SocketInputStream
>>     sun/nio/ch/SocketChannelImpl
>>     java/io/FileOutputStream
>>     java/lang/Error
>>     sun/nio/ch/FileChannelImpl
>>     java/io/FileInputStream
>>     java/io/RandomAccessFile
>>
>> The change passed hs-tier[1,2,3] testing.
>>
>> thanks,
>>
>> Calvin
>>
>


More information about the hotspot-runtime-dev mailing list