[PATCH] JFR thread sampling issue

[Erik Gahlin]

Hello Milan, 

The thread sampling mechanism was changed. Sampling now happens in a dedicated thread, which means it is possible to set a higher sampling rate than 10 ms. Sampling of threads in native was also added.

I must go back and look at the code for earlier releases, before I can determine what has happened. That said, I can sponsor your patch and file a JIRA bug for you.

I will get back to you.

Thanks
Erik

> On 19 Nov 2018, at 13:41, Milan Mimica <milan.mimica at gmail.com> wrote:
> 
> Hello
> 
> I was regularly using JFR to profile my service and thread sampling results
> have been very useful. Unfortunately, when I have switched to Java 9 and
> afterwards, it stopped working. The recording would catch too few samples
> for the results to be useful. My service has about 500 threads, most of
> them being on some blocked state.
> 
> With the release of Java 11, I have started digging into the JFR source
> code and I think I have found the problem. I think
> JfrThreadSampler::task_stacktrace is supposed to find at most 5 threads
> that are in state _thread_in_Java, or at most 1 thread that is in
> _thread_in_native, but instead it just picks next 5 (or 1) threads and then
> ignores them of they are not in right state. Without the insight into code
> change prior to JDK 11 I can just guess, but there are some clues that lead
> me to think that's how it was supposed to work. One of the clues is that
> sample_task.do_sample_thread returns a result that is otherwise unused.
> 
> I'm attaching a patch.
> Tested test-jdk_jfr_sanity on fastdebug, and in my production.
> 
> I'm waiting for my Author status approval so I'll be able to create a
> proper changeset. I believe I also need a ticket for this.
> 
> 
> -- 
> Milan Mimica
> <jfr-sampling.patch>