Java: Remove source dispatch when there's an exact match from a manual model.

[aschackmull]

This blocks source dispatch when we have an exact match from a manual model, thus improving analysis when analysing the db containing the source for a given manual model. I.e. this only affects projects for which there exists some number of manual models.

[owen-mc]

Can you explain in a bit more detail what this does? I'm not totally sure what "source dispatch" is.

From what I can tell, one effect of this PR is that using the shortcut of not listing the signature (because I know that there is only one method with that name, or because I don't want to spend time listing all the methods with that name) will now behave differently from having a model which has the signature. At the very least this should be communicated widely, and perhaps documented somewhere.

[aschackmull]

Can you explain in a bit more detail what this does? I'm not totally sure what "source dispatch" is.

For every manual model, this change affects only one single projects, namely the one containing the source implementation. Take for example java.lang.String.replace. When analysing the jdk we would get dispatch to both the source implementation of String.replace and also the MaD-synthesised method body. This change ensures that we only get the latter. Most (all?) of our manual models that refer to non-interface methods are describing jdk methods, so this change is fairly targeted to the analysis of openjdk itself.

Whether or not we should include the "empty signature" check to determine whether we disregard the source dispatch target is something that we can change if we want - I opted for the most conservative version here. I'm not sure that this actually needs to be that widely documented, since it only affects analysis of one project (per manual model).

[owen-mc]

Okay. I do think this changes the best-practice to be including the signature, though as most modelling is automated this won't make too much difference.

Does this improve performance on the JDK then? Analysis time got 20% longer when I added all the df-generated models, and I wasn't able to figure out where the time was being spent.

[aschackmull]

Does this improve performance on the JDK then?

Yes. I've only measured this in the context of #16500 where the 60% regression was reduced to a 19% regression.

[owen-mc]

It would be good to run DCA on this (possibly just with the JDK source) to quantify how much of the performance hit from adding the jdk models it mitigates. For reference, that made analysis time on the jdk go from 435.3s to 526.7s.

Should this change also be made to other languages? (Not necessarily in this PR.) I'm particularly aware of this as I've got a branch where I've updated the go version to match the java version as much as possible, and this PR will introduce another unnecessary difference.

[aschackmull]

It would be good to run DCA on this

I've started dca.

Should this change also be made to other languages?

Probably, yes.

[aschackmull]

Actually, from re-visiting some of my notes, I do think we have several cases where it's desirable to consider a model an exact match based solely on the package+type+name, and not consider the signature. So I'll try to make that change and kick off another dca.

[aschackmull]

We might even want to go as far as looking for package matches rather than exact matches. That way a manual model for an interface would take complete precedence over any source implementations of that interface in the same package - even if they had direct calls that didn't go through the interface. But I think I'll leave that option for now and stick with the "exact match" concept. I'm just noting this for future reference.

[aschackmull]

It would be good to run DCA on this (possibly just with the JDK source) to quantify how much of the performance hit from adding the jdk models it mitigates. For reference, that made analysis time on the jdk go from 435.3s to 526.7s.

The first variant showed a 23% time decrease from 598.7s to 459.7s. The second variant showed a 33% time decrease from 581s to 388.3s.

[aschackmull]

Looks like I'll need to rebase to satisfy CI.

[owen-mc]

Final question: why choose the model over the source code? Do you think they're more accurate? Is performance an issue? I assume using the model is faster as the paths will be much simpler. I can see it's more consistent, as we use the models when analysing every other repo.

[aschackmull]

Final question: why choose the model over the source code? Do you think they're more accurate? Is performance an issue? I assume using the model is faster as the paths will be much simpler. I can see it's more consistent, as we use the models when analysing every other repo.

All of those reasons apply. It's more consistent, paths will be simpler, flow will be more accurate, and as we can see, performance also improves significantly.