Impossible stack traces

[hysoqvs0sb8 at tutanota.com]

Hi Markus/Everyone,

So far I've been unable reproduce this behaviour the way I wanted, but now I have something that kind of works, you can check it out on GitHub:

https://github.com/novakzs/jfrdemo

In case it doesn't work for you, I've attached a few recordings, so at least you can see what I see.

The problem here is that even though the program uses HashMaps only, there are some method sampling events where the stack trace contains calls to LinkedHashMap methods.  

void java.util.HashMap$Node.<init>(int, Object, Object, HashMap$Node)	201 
---void java.util.LinkedHashMap$Entry.<init>(int, Object, Object, HashMap$Node)	200
------HashMap$Node java.util.LinkedHashMap.newNode(int, Object, Object, HashMap$Node)	200
---------Object java.util.HashMap.putVal(int, Object, Object, boolean, boolean)	200
------------Object java.util.HashMap.put(Object, Object)	200
---------------void demo.jfr.methodsampledemo.CL5.innerWork(int, int)	198

In this case for example, the CL5.innerWork() method just puts some stuff into a HashMap, there is no LinkedHashMap in sight.

For the 4th recording, I've added a custom jfr event to the LinkedHashMap.newNode() method, just to confirm that there is no black magic involved. The suspicious method samplng events are still there, and my custom event does not collect anything to indicate that they are real.


There are some differences between this program and my application that may be of interest:

- the numbers: in my application, about 5+% of the method sampling events are suspicious.

- the standard libraries don't have to be involved, I have seen some of these phantom stack traces where every call was from my application.

- in some cases, when I wanted to confirm that a method is not called often, putting a custom event into the method completely obliterated the method sampling events that contained that call. The event did not have to be active or collect anything, it had an effect on behaviour just by being there. If I then removed the event, everything went back to "normal" and the bad method sampling events reappeared.



with best regards,
Zsolt N.

2020. szept. 24. 18:43 tőle: markus.gronlund at oracle.com:

> Hi,
>
> Thanks for bringing this to attention. I have tried to reproduce this issue today but I am yet unable to do so.
>
> Is it possible for you to provide a reproducer?
>
> Thanks
> Markus
>
> -----Original Message-----
> From: hysoqvs0sb8 at tutanota.com <hysoqvs0sb8 at tutanota.com> 
> Sent: den 23 september 2020 22:07
> To: hotspot-jfr-dev at openjdk.java.net
> Subject: Impossible stack traces
>
> Hello,
>
> Lately I have noticed that sometimes my method profiling events show stack traces that should not happen under any circumstances.
>
> As an example, there is a class that looks roughly like this:
>
> class SomeClass { 
>       private Map<Integer, SomeOtherClass> map = new HashMap<>();
>      ...
>      map.put(0, new SomeOtherClass());
>      map.put(1, new SomeOtherClass());     
>      ...
>      public SomeOtherClass get(int key) {          return map.get(key);     }}
>
> I have confirmed that the map only ever holds those two keys.
> The top of some stack traces captured by method profiling events then look like this:
>
> HashMap$TreeNode java.util.HashMap$TreeNode.getTreeNode(int, Object) 
>      HashMap$Node java.util.HashMap.getNode(Object)          Object java.util.HashMap.get(Object)               	SomeOtherClass SomeClass.get(int)
>
> I have ran into this issue with jdk15 and some later ea builds, on windows, and 1ms sampling periods, can any of these be the cause of this issue?
>
> with best regards,
> Zsolt N.
>