RFR: 8237499: JFR event for the location where a new thread starts

Erik Gahlin erik.gahlin at oracle.com
Tue Jan 28 21:50:57 UTC 2020


Looks good!

Thanks for fixing this.

Erik

On 2020-01-28 18:07, Denghui Dong wrote:
> Good explanation!
> The webrev has been updated, please help review it :)
>
> Denghui Dong
>
>     ------------------------------------------------------------------
>     From:Erik Gahlin <erik.gahlin at oracle.com>
>     Send Time:2020年1月28日(星期二) 20:38
>     To:董登辉(卓昂) <denghui.ddh at alibaba-inc.com>; hotspot-jfr-dev
>     <hotspot-jfr-dev at openjdk.java.net>
>     Subject:Re: RFR: 8237499: JFR event for the location where a new
>     thread starts
>
>     Hi Denghui,
>
>     On 2020-01-24 04:44, Denghui Dong wrote:
>     Hi Erik,
>      > set stackTrace="true" in metadata.xml
>      Actually, I thought about it before. But two thing let me add a
>     new field explicitly finally:
>     1. EventThreadStart was also posted in jni.cpp, and there is no
>     need to record the stack trace, we cannot control it if setting
>     stackTrace="true".
>
>     Not sure I understand, but in jni.cpp you could do what you do
>     today (set it to 0).
>
>     For jfrThreadLocal.cpp, you could check
>     JfrEventSetting::has_stacktrace(EventThreadStart::eventId)).
>
>
>     2.  I think adding an explicit filed can make us and users clear
>     that the stack trace isn't recorded from the new thread but the
>     parent thread. And
>     there are also other events that have an explicit stack trace
>     field(e.g. ExecutionSample).
>
>
>     ExecutionSample and NativeMethodSample should probably have
>     stackTrace="true" as well.
>
>     I don't think it matters from users point of view if the field is
>     added implicitly or explicitly. Maybe if it was called
>     "parentStackTrace", but that would lead to problems for JMC and
>     the parser since they depend on the field being called
>     "stackTrace". For us, it would make it more clear, but perhaps not
>     that important.
>
>
>     Another reason we may want to make the stack trace part of the
>     event is that it will make it easier to configure. For example, we
>     plan to add so you can set stack depth per event, for example in
>     the JMC recording wizard.
>     https://bugs.openjdk.java.net/browse/JDK-8134306
>
>     Thanks
>     Erik
>
>
>      > change the label of the thread field from "Java Thread" to "New
>     Thread"
>      It makes sense, I will update it.
>
>     Thanks
>     Denghui Dong
>     ------------------------------------------------------------------
>     From:Erik Gahlin <erik.gahlin at oracle.com>
>     Send Time:2020年1月23日(星期四) 21:44
>     To:董登辉(卓昂) <denghui.ddh at alibaba-inc.com>; hotspot-jfr-dev
>     <hotspot-jfr-dev at openjdk.java.net>
>     Subject:Re: RFR: 8237499: JFR event for the location where a new
>     thread starts
>
>     Hi Denghui,
>
>     Would it be possible to set stackTrace="true" in metadata.xml
>     instead of adding a new field explicitly?
>
>     This allows users to turn on and off stack traces. You could check
>     if stack trace is enabled and only record if needed.
>
>     I think it would be good to change the label of the thread field
>     from "Java Thread" to "New Thread".
>
>     Thanks
>     Erik
>
>     On 2020-01-19 09:13, Denghui Dong wrote:
>     Hi Erik
>       The webrev has been updated.
>       I reuse the event type "EventThreadStart" to report the location
>     where a new thread starts.
>       Add two fields "stackTrace" and "parentThread" to EventThreadStart.
>       Please help review it, thanks.
>
>     Best Regards
>     Denghui Dong
>     ------------------------------------------------------------------
>     From:董登辉(卓昂) <denghui.ddh at alibaba-inc.com>
>     Send Time:2020年1月18日(星期六) 21:25
>     To:Erik Gahlin <erik.gahlin at oracle.com>; hotspot-jfr-dev
>     <hotspot-jfr-dev at openjdk.java.net>
>     Subject:Re: RFR: 8237499: JFR event for the location where a new
>     thread starts
>
>     Hi Erik,
>       Do you mean that we should reuse EventThreadStart rather than a
>     new event? It's a good idea, I will try it.
>
>     Thanks
>     Denghui Dong
>     ------------------------------------------------------------------
>     From:Erik Gahlin <erik.gahlin at oracle.com>
>     Send Time:2020年1月18日(星期六) 21:12
>     To:董登辉(卓昂) <denghui.ddh at alibaba-inc.com>
>     Cc:hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>
>     Subject:Re: RFR: 8237499: JFR event for the location where a new
>     thread starts
>
>     Hi Denghui,
>
>     This will be useful, but I wonder if we shouldn’t extend the Thread Start event with stack trace and the parent thread? It will require some additional logic, but it would be a cleaner solution.
>
>     Thanks
>     Erik
>
>     > On 18 Jan 2020, at 12:19, Denghui Dong
>     <denghui.ddh at alibaba-inc.com> wrote:
>     >
>     > Hi,
>     >
>     > Could I have a review of a change that introduces an event for the location where a new thread starts.
>     >
>     > Summary:
>     > There is already an event for thread start(EventThreadStart), but this event is committed in the new thread,
>     > so users can't know the location where the thread starts, hence, it's necessary to introduce another event,
>
>     > it would be useful if the application exists thread leak problem.
>     >
>     > Bug: https://bugs.openjdk.java.net/browse/JDK-8237499
>     > Webrev: http://cr.openjdk.java.net/~ddong/8237499/
>     >
>     > Thanks
>     > Denghui Dong
>     >
>


More information about the hotspot-jfr-dev mailing list