JDK-8210977 : jdk/jfr/event/oldobject/TestThreadLocalLeak.java fails to find ThreadLocalObject
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 11,13
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-09-20
  • Updated: 2020-11-26
  • Resolved: 2020-02-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 JDK 13 JDK 15
11.0.9-oracleFixed 13.0.6Fixed 15 b11Fixed
Related Reports
Relates :  
JDK-8202662 - JFR tests fails: Could not find leak with class
Description
This one fails pretty frequently in Twitter's nightly testing when running with Graal:

java.lang.Exception: Could not find thread local object class jdk.jfr.event.oldobject.TestThreadLocalLeak$ThreadLocalObject
	at jdk.jfr.event.oldobject.TestThreadLocalLeak.main(TestThreadLocalLeak.java:66)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
	at java.base/java.lang.Thread.run(Thread.java:834)
Comments
Fix Request (13u) Requesting backport to 13u for parity with 11u. This is a test only change that increases tests stability. The original patch applies cleanly. The affected test passes.
17-11-2020
Fix request Patch applies cleanly.
26-05-2020
[~shade] are you planning to backport this to 11?
19-03-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/a614219d7388 User: egahlin Date: 2020-02-18 21:26:23 +0000
18-02-2020
Other old object event tests retries until they succeed. This doesn't. I will add a loop and see if it helps.
17-02-2020
Yes: @requires !vm.graal.enabled
28-01-2020
> Is that the desired behavior? Yes, it will keep object samples evenly distributed over "time" (really amount of allocated memory). Graal creates allocation samples which pushes objects out from the queue. Is there a way to exclude tests for Graal, i.e @requires graal == null
23-01-2020
It turns out JVMCI CompilerThreads are not the only source of interference. The "JFR Periodic Tasks" thread also posts events during the test. The following patch makes the test more resistant to interference: http://cr.openjdk.java.net/~dlong/8210977/webrev/ In the future it might be useful to allow the recording of events only for a particular set of threads.
16-10-2018
Interesting. I hope we are not waiting for libgraal for a fix...
16-10-2018
Reassigned to jfr for evaluation.
14-10-2018
Presumably, when we have libgraal, Graal allocations won't be visible to JFR.
14-10-2018
[~egahlin] Hi Erik, it looks like you worked on this code in the past. Can you describe what's supposed to happen when the ObjectSampler queue fills up? It looks like the quick-reject path if (peek->span() > span) { will not be taken after a while, because "span" grows with the total amount allocated: const size_t span = _total_allocated - _priority_queue->total(); So eventually we will be replacing the smallest element with the new element: sample = _list->reuse(_priority_queue->pop()); Is that the desired behavior?
11-10-2018
It looks like the problem is the default value of the JFR old-object-queue-size, which is 256, and the fact that the test doesn't expect there to be a significant amount of other JFR events being created during the test. Normally this would be true, but with Graal the JVMCI compiler threads are also generating JFR events. Workaround: -XX:FlightRecorderOptions=old-object-queue-size=10000 I'm not a JFR expert. Is there a way to restrict event recording only to events generated by the requesting thread? Or would it make sense to disable JFR events from JVMCI threads?
10-10-2018
OK, I tried again and it's failing about 50% of the time, which is weird because I don't see the test methods getting compiled by Graal.
09-10-2018
No, and I haven't been able to reproduce it. What command-line flags are you using?
09-10-2018
Do you Oracle people see this issue as well?
01-10-2018
The only related bug I could find is JDK-8202662 which was fixed a while ago and had a different failure message.
20-09-2018