Include observed types per trace in each report

[Sanne]

One of the interesting reports we recently investigated shows this information:

12:     java.util.ArrayList
Count:  1519784
Types:
        java.lang.Iterable
        java.util.List
        java.util.Collection
Traces:
        io.vertx.ext.web.impl.RoutingContextImpl.getQueryParams(RoutingContextImpl.java:462)
                class: java.lang.Iterable
                count: 761561
        org.jboss.resteasy.reactive.server.mapping.RequestMapper.map(RequestMapper.java:62)
                class: java.util.List
                count: 757704
        io.vertx.core.http.impl.SharedClientHttpStreamEndpoint.lambda$checkExpired$4(SharedClientHttpStreamEndpoint.java:117)
                class: java.util.List
                count: 216
        org.jboss.resteasy.reactive.common.util.MultivaluedTreeMap.putAll(MultivaluedTreeMap.java:185)
                class: java.util.List
                count: 75
...

After some digging in the source code of vert.x's RoutingContextImpl, we figured that this is most likely a false positive being reported as the particular code in that class is bound to ever only observe the java.util.ArrayList type being used, hence triggering type optimisation and most likely also making the other 3 cases reported above a non-problem.

We already know from the first line of the report that this was about java.util.ArrayList, but I think it would be helpful to list all observed types in a particular trace and I suspect this could be implemented without slowing down the agent significantly.

As an example, we could have:

Traces:
        io.vertx.ext.web.impl.RoutingContextImpl.getQueryParams(RoutingContextImpl.java:462)
                class: java.lang.Iterable
                count: 761561
                types: { java.util.ArrayList }

N.B. that's a list of observed types.

I realize this won't guarantee that in other usage patterns of the same library there won't be other types being observed, yet I consider this useful information when exploring a non trivially sized report as it would help prioritize analysis.

So I wouldn't suggest that the presence of a single type to be taken as exhaustive information to make a judgement, but in terms of priorities I know I most likely want to focus on the ones in which multiple types are being listed.

It's also useful to have this information to cross-check the findings we might gather by reasing the actual source code of the affected method.

Thanks :)

[franz1981]

Thanks to the additional Miss we now have a nearly complete pictures of all the types checked against:

• the ones which flip-flop the cache
• the ones which cross a type check but doesn't implement it

The last one missing are:

• the ones which correctly use the cache without any flip flop

It is very feasable to do it (we already have, regardless any ssc flip-flop, a ClassValue per concrete type used as receiver of a type check), let me check if I have some free cycles this or next week, if you are still interested in it @Sanne