JDK-8262121 : [11u] Redo 8244287: JFR: Methods samples have line number 0
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 11
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-02-22
  • Updated: 2024-12-05
  • Resolved: 2021-03-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11.0.12 b01Fixed
Related Reports
Relates :  
JDK-8313802 - [11u] Test jdk/jfr/event/sampling/TestStackFrameLineNumbers.java is unstable
Relates :  
JDK-8253813 - Backout JDK-8244287 from 11u: it causes several crashes
Relates :  
JDK-8244287 - JFR: Methods samples have line number 0
Description
The downport of 8244287 to 11 was backed out after it caused crashes.

Redo the change, also adding a constructor that takes method and lineno.
Comments
URL: https://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a75d92bcfbf3 User: goetz Date: 2021-05-05 12:03:09 +0000
05-05-2021
URL: https://hg.openjdk.java.net/jdk-updates/jdk11u-dev/rev/a75d92bcfbf3 User: goetz Date: 2021-03-18 11:07:48 +0000
18-03-2021
Hi Goetz, I checked the test and the failure is caused by missing execution samples. Parking for ~1s (even with short intermediary steps) might not generated enough 'load' to produce any execution samples. When I added a busy dummy code instead of parking (doing some random iterations of random numbers accumulation) the test started passing 100% (so far 100 consequent test runs without a failure). While looking at the test failure cause I came to wonder why JfrStackTrace::record_safe() is not using the same 'best effort' to retrieve the line number info. It seems that in the worst case the information will not be available and we end up without line number info - but at least we would have consistent data between those two methods capturing stack traces. EDIT: Got a response from ~mgronlun {block} Line number information is kept outside of the hash and calculated lazyily for the synchronous case because method->line_number_from_bci() is very slow. We try to avoid calculating it as long as possible; you can see JfrStackTraceRepository::add() reject a new trace if lineno info is not available, and only at this time will it be resolved. {block} So, my suggestion is invalid and the change is good as it is.
10-03-2021
Hi Jaroslav, I already sent a webrev to fix this. Unfortunately, the test fails on some platforms. I did not have the time to look into that, that's why it is stalled. http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2021-February/005079.html jdk/jfr/event/sampling/TestStackFrameLineNumbers.java java.lang.Exception: No line number information found at jdk.jfr.event.sampling.TestStackFrameLineNumbers.main(TestStackFrameLineNumbers.java:82) It happens on all platforms, but only quite sporadic, maybe every other 20th run. Feel free to take over ...
09-03-2021