do not use Objects.hash in ExpressionContext or FunctionContext

[richardstartin]

I noticed very high allocation rate from using ExpressionContext as a HashMap key when profiling a benchmark:

This is because Objects.hash boxes its arguments.

Computing the hash code manually reduces allocation in benchmark runs significantly:

before

Benchmark                                                                               (_intBaseValue)  (_numRows)  Mode  Cnt        Score          Error   Units
BenchmarkFilteredAggregations.testFilteredAggregations:·gc.alloc.rate.norm                            0     1500000  avgt    5   477029.513 ±     4265.923    B/op
BenchmarkFilteredAggregations.testNonFilteredAggregations:·gc.alloc.rate.norm                         0     1500000  avgt    5  1453348.554 ±    38671.676    B/op

after

Benchmark                                                                               (_intBaseValue)  (_numRows)  Mode  Cnt        Score          Error   Units
BenchmarkFilteredAggregations.testFilteredAggregations:·gc.alloc.rate.norm                            0     1500000  avgt    5   372573.234 ±   299663.490    B/op
BenchmarkFilteredAggregations.testNonFilteredAggregations:·gc.alloc.rate.norm                         0     1500000  avgt    5  1085451.680 ±  1751019.851    B/op

[siddharthteotia]

Do we need to see if arguments.hashCode() internally uses Objects.hash() and if that needs to be fixed too ?

[richardstartin]

Fortunately we don’t- the frames for ArrayList are in the flame graph above. After this change, that whole stack trace disappears from allocation profiles.