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