Improve DefaultCodecRegistry.CacheKey#hashCode() to eliminate Object[] allocation

[tatu-at-datastax]

So: while this may seem trivial, profiling showed significant Object[] allocations here (since Object.hashCode(Object... args) takes varargs which gets converted into Object[]) so figured out it's worth improving upon.
Should produce same hash code (although that should not matter greatly as long as hash code works well enough).

[tatu-at-datastax]

Looks like there is no CI (Github Actions) set up; but local mvn clean test did pass FWTW.

[tatu-at-datastax]

Not sure what to do wrt CI, due to simplicity of change guessing there are transient failures.

@absurdfarce Not a big deal but this seems like a simple fix, low-hanging fruit (as per my note was seen at a mem-alloc profiling)

[SiyaoIsHiding]

According to List.hashCode()

     int hashCode = 1;
     for (E e : list)
         hashCode = 31*hashCode + (e==null ? 0 : e.hashCode());

Isn't it ((31+h1)*31+h2)*31+h3?

[tatu-at-datastax]

True. I missed the initial multiplication. Will change.

[tatu-at-datastax]

Changed as suggested.

[SiyaoIsHiding]

Thank you for the fix! Makes sense to me. Another outstanding PR is also about Objects.hash() Object[] allocation performance issues discovered by profiling. It makes me wonder what else Objects.hash() we should fix. We have a lot of Objects.hash() in our codebase.

[tatu-at-datastax]

Thank you for the fix! Makes sense to me. Another outstanding PR is also about Objects.hash() Object[] allocation performance issues discovered by profiling. It makes me wonder what else Objects.hash() we should fix. We have a lot of Objects.hash() in our codebase.

Interesting & good question. I think most of those cases do not probably matter that much (not in hot path of code flow) so it might be ok to change only cases that show up in profiling?

Then again it might not be bad idea to have a look at how many other cases exist.

[SiyaoIsHiding]

A quick text search of Objects.hash returns 60 matches in our codebase. In that case we probably should just implement our own util.objectsHash.

[tatu-at-datastax]

@SiyaoIsHiding if that can be done, sure. But since the allocation comes from varargs parameter, it probably requires a few overloads (with 1, 2, 3 field values to hash).

[SiyaoIsHiding]

Filed ticket as CASSJAVA-68.