RFR: 8311902: Concurrency regression in the PBKDF2 key impl of SunJCE provider [v2]

[Valerie Peng]

On Fri, 14 Jul 2023 03:04:13 GMT, Xue-Lei Andrew Fan <xuelei at 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