-
Bug
-
Resolution: Fixed
-
P3
-
11, 12, 13
-
b02
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8219342 | 12.0.2 | Markus Grönlund | P3 | Resolved | Fixed | b01 |
JDK-8217839 | 11.0.4-oracle | Markus Grönlund | P3 | Resolved | Fixed | b01 |
JDK-8217931 | 11.0.3-oracle | Markus Grönlund | P3 | Resolved | Fixed | b05 |
JDK-8219347 | 11.0.3 | Markus Grönlund | P3 | Resolved | Fixed | master |
JDK-8254684 | openjdk8u282 | Markus Grönlund | P3 | Resolved | Fixed | b01 |
Attaching description mail from Milan Mimica describing the situation and suggesting a patch:
"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."
"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."
- backported by
-
JDK-8217839 Restore JFR thread sampler loop to old / previous behavior
- Resolved
-
JDK-8217931 Restore JFR thread sampler loop to old / previous behavior
- Resolved
-
JDK-8219342 Restore JFR thread sampler loop to old / previous behavior
- Resolved
-
JDK-8219347 Restore JFR thread sampler loop to old / previous behavior
- Resolved
-
JDK-8254684 Restore JFR thread sampler loop to old / previous behavior
- Resolved