On Fri, 14 Jul 2023 03:04:13 GMT, Xue-Lei Andrew Fan <xue...@openjdk.org> wrote:
> > > > It looks good to me to rollback to previous behaviors. I was just > > > > wondering, if the use of key in other methods, like > > > > hashCode()/equals(), has the similar issue? Thanks! > > > > > > > > > For the usage of hashCode()/equals(), there should be strong reference to > > > the key object for the usage scenarios I'd think. Thus, probably not an > > > issue? > > > > > > Yes, it makes sense to me. > > I may reply too quickly to get the idea. Why you think there will be strong > reference to the key object for hashCode()/equals(), but not for > getEncoded()? I did not get the idea. hashCode()/equals() are normally used when objects are still around, e.g. used in hash map. As for getEncoded(), callers may just want to retrieve the bytes and not keep the Key object. After some internal discussion, I am inclined to include all methods including the hashCode(), equals() into this reachabilityFence() change for the sake of consistency. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14859#issuecomment-1636478233
