RFR(S): 8203664: JFR start failure after AppCDS archive created with JFR StartFlightRecording
Calvin Cheung
calvin.cheung at oracle.com
Wed Jun 20 18:18:48 UTC 2018
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