Java: Performance fixes for local flow relation

[aschackmull]

The local flow relation was accidentally made mutually recursive with AdditionalValueStep. It makes sense to allow the use for local flow to define AdditionalValueStep::step, so removing the latter from the former allows this without recursion.

A non-monotonic dummy reference is added to prevent re-introduction of recursion here, and this highlighted the need for a minor refactor in FlowSummaryImpl (since ReturnNodeExt depends on local flow).

The local flow relation is also fixed to force the use of the fastTC hop, as this otherwise was observed to result in a very slow materialisation.

[atorralba]

Looks plausible to me, just one minor comment.

There are a couple of tricks (namely fastTC and (any() or strictcount(Node n1, Node n2, AdditionalValueStep a | a.step(n1, n2)) < 0)) that I would like to learn more about at some point, though :)

[aschackmull]

There are a couple of tricks (namely fastTC and (any() or strictcount(Node n1, Node n2, AdditionalValueStep a | a.step(n1, n2)) < 0)) that I would like to learn more about at some point, though :)

fastTC just means the same as the + suffix on a predicate, but forces the compiler to use the specialised code for this (using + leaves the choice to the optimiser, which will often also result in using fastTC, but didn't in this case (and that happened to be bad)).
The other ugly line of obscure QL is a hack. It doesn't really matter much what it contains as and (any() or ...) optimises away to nothing at all, but a predicate reference inside a strictcount can't be recursive, so we ensure that we don't introduce accidental recursion in the future through this hack.

[hvitved]

There are some large regressions for Ruby; could be because of the missing pragmas mentioned above.

[aschackmull]

DCA looks good now.