RFR: 8329968: os::random should be random
Thomas Stuefe
stuefe at openjdk.org
Tue May 28 08:42:01 UTC 2024
On Tue, 28 May 2024 02:24:33 GMT, David Holmes <dholmes at openjdk.org> wrote:
> > Random distribution of ihashes. Atm, ihashes are always the same for the same sequence of System.identityHashCode.
>
> And this is a problem because???
A feeling of unease. I cannot conjure an attack scenario up that relies on predictable ihashes, but that does not mean there is none. And, inversely, you probably cannot prove that there is none either. Therefore, In the end, it comes down to a risk assessment.
> Conversely if you change the ihashes every time an application runs what affect does this have on the general performance of hashmaps? Does this not introduce some instability? Could some seeds lead to pathological hashmap behaviour?
That is possible, albeit unlikely. I tested the RNG yesterday (after falsely thinking the RNG had a bad distribution) with a large number of different seeds, and the distribution seemed to be fine for all testd seeds. (There was an oddity if the seed was 0, but I did not dive into that).
Considering that today's ihash generation start being more random if multiple threads come into play, I would guess different seeds should not be a problem.
>
> > We use os::random to fuzzing gtests
>
> Can you not use FastRandom for that? Or employ the same technique that FastRandom does?
Certainly. That is my fallback plan if we don't fix os::random.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/18702#issuecomment-2134655569
More information about the hotspot-runtime-dev
mailing list