RFR: 8221836: Avoid recalculating String.hash when zero

Andrew Dinn adinn at redhat.com
Tue Apr 9 08:20:31 UTC 2019


On 08/04/2019 22:19, Claes Redestad wrote:
> First, I disagree strongly that this patch adds significant complexity
> (especially after recent simplifications[1]) or that it risks increasing
> maintenance headache down the line.

It all depends what you mean by significant. It definitely adds
complexity. If there are other benefits than the rather questionable one
of avoiding infrequent zero hashes they may well justify that complexity.

> Secondly, I think the gain w.r.t. defense-in-depth is very real. Sure,
> we have alt-hashing and similar counter-measures in various JDK
> collection libraries, but that is unlikely to help every API or library
> ever invented out there.

This is a better argument.

> Third... well, the other performance gains are of course nice-to-
> have - improvements to "".hashCode() and allowing String deduplication
> to not have to filter out such Strings - but I agree that they are
> likely mostly theoretical for anything real-world.

Ok, so the argument is DID then? I'll buy that.

> If this change then exposes a bug in some unexpected place elsewhere
> (I can only guess what dangers lurks out there... unforeseen interaction
> with a weaker memory model? some wonky JIT reordering?) then that might
> even be for the better in the end. If/when that happens, we can opt to
> back this out (or not) while addressing whatever issue we've unearthed.
I don't believe Aleksey is suggesting that some hidden memory ordering
or JIT transformation bug may come to bite us. As I understand it the
problem he is concerned with is subsequent injection of such a bug i.e.
some developer 1) not recognising that the code as it stands only works
in the presence of these re-ordering possibilities by careful design and
2) mistakenly changing the code so that those possibilities are no
longer bypassed. I agree that is a real concern. If the patch is to go
in -- and I concede there is an acceptable argument for that -- then it
needs commenting to help avoid this happening.

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander



More information about the hotspot-gc-dev mailing list