RFR(trivial): 8222394: HashMap.compute() throws CME on an empty Map if clear() called concurrently

[Stuart Marks]

On 5/4/19 12:21 AM, Patrick Zhang OS wrote:
> Thank you very much for the detailed explanation and examples, which solved most of my previous questions and confusion. Really appreciate that. I agree with the opinion about "effort vs benefit".
> 
> Re-thought my original tests concerning CMEs that passed with jdk8u but failed with jdk11 (should be 9+, but I only checked LTS builds), I was struggling between "fixing" the "problems" in jdk11 and "making jdk8 fail similarly". However so far it looks these tests might be over strict, or "verifying CMEs" itself might be an invalid (or unreliable) operation, perhaps I should drop all of them. Lastly, a suggestion would be: adding more comments for this in case anyone else would revisit it with similar confusions, e.g. HashMap.clear.

Great, I'm glad this was helpful.

Regarding the tests, yes, I'm afraid those might be overly strict. The 
specification is admittedly quite loose in this area. This means that the exact 
behavior may vary from release to release. If a collection is optimized, for 
example, sometimes it's quite difficult to preserve the exact same behavior in 
all cases. It's for this reason we avoid specifying the exact behaviors around 
CME. Of course, when making any changes, we usually do try to preserve the 
general behavior, just not every specific edge case.

I generally welcome code comments to improve clarity, but I'm not sure one is 
warranted for HashMap.clear(). The placement of modCount++ seems quite 
reasonable. There are other cases where the choice of 
conditional-vs-unconditional is made (see [1]) and I don't think we want to go 
sprinkling explanations of this all around the code.

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060068.html

s'marks