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