[
https://issues.apache.org/jira/browse/CALCITE-3836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17051095#comment-17051095
]
Stamatis Zampetakis commented on CALCITE-3836:
----------------------------------------------
Even though it can be classified as an improvement, I think we are really in
the borders of premature optimization.
The vast majority of Calcite APIs are not meant to be used concurrently and
this is also true for RelNode. If understood well the change is not going to
bring any real improvement in the existing use cases at the moment.
Furthermore, in the future the JVM implementations may change making this
change unnecessary or even less efficient.
Last, if we allow this kind of change for RelNode then why not doing a similar
thing for every other class that relies on the identity hash code.
> The hash codes of RelNodes are unreliable
> -----------------------------------------
>
> Key: CALCITE-3836
> URL: https://issues.apache.org/jira/browse/CALCITE-3836
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Liya Fan
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 1h
> Remaining Estimate: 0h
>
> For all sub-classes of AbstractRelNode, the {{hashCode}} methods depend on
> {{AbstractRelNode#hashCode}}, because it is declared as final.
> {{AbstractRelNode#hashCode}} depends on {{Object#hashCode}}, which is called
> identify hash code. The details of identity hash code depends on the specific
> JVM implementation. For many JVMs, the implementation is based on the object
> address in the memory. The problem is that, the address of an object may
> change in a JVM, due to GC, memory contraction, etc. So the hash code of an
> object may change, even if the content of the object is not changed (This can
> be confirmed from the JavaDoc of {{Object#hashCode}}).
> This problem may cause severe issues that are hard to diagnose and debug,
> like an object is in the hash table, but cannot be retrieved; duplicate
> objects in the hash map, etc.
> To solve the problem, we compute a hash code solely from the node id. This is
> consistent with the previous semantics, and solves the above problem.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
