RFR(S): 8210024: JFR calls virtual is_Java_thread from ~Thread()

Kim Barrett kim.barrett at oracle.com
Wed Nov 14 01:11:36 UTC 2018


> On Nov 12, 2018, at 7:58 AM, Markus Gronlund <markus.gronlund at oracle.com> wrote:
> 
> Greetings,
> 
> Please review the following changes to help make the JFR deregistration / buffer release steps a bit more robust as thread exits.
> 
> There is a need to release the JNIHandle for the EventWriter while the JavaThread is still on the threads list, since there is a sensitive interplay with the G1-prebarrier, and this change will help assist in the removal of shared PtrQueues.
> 
> The virtual is_Java_Thread() call can still be invoked for the NonJavaThreads in their destructor, but since the thread is still a NonJavaThread at this point, it should be possible to make is_Java_thread() pure virtual in Thread.
> I did not find any proper non-platform specific exit location for NonJavaThreads, so they release as part of the destructor. 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210024 
> Webrev: http://cr.openjdk.java.net/~mgronlun/8210024/webrev01/ 
> Testing: JFR tests, tier1, tier2, tier3

I don't know the JFR code well enough to thoroughly review this, but
the interactions with GC and thread iteration look good.

There should probably be an RFE to make is_Java_thread() pure virtual.



More information about the hotspot-jfr-dev mailing list