Potential hash collision by using v8::Module::GetIdentityHash() about rusty_v8 HOT 9 CLOSED

I came across this when searching for other projects having issues with GetIdentityHash. Circling back around just to say that I found out it's only 21 bits now, so we in another project were having issues with collisions in just hundreds of instances.

from rusty_v8.

Ok thanks - good to know.

from rusty_v8.

Hi! Is there an estimate on this issue? We're using GetIdentityHash() to identify objects, and we would like to know if we can rely on it or not.

from rusty_v8.

@zbendefy I've had no problems with it.

from rusty_v8.

@ry We'll use potentially thousands of objects, that we are identifying (for storage in a hashmap) using GetIdentityHash(). We didn't do thorough testing yet, but having a Stable way to identify JS objects would be nice.

I presume that we cannot use the underlying pointer values behind a Local<> or Persistent<> handle?

from rusty_v8.

@ry Is this still relevant?

from rusty_v8.

Yes

from rusty_v8.

These bindings are now in rust_v8 so I moved it.

from rusty_v8.

This is not for rusty_v8 to fix. The identity hash itself isn't buggy but it can be used in a way that introduces bugs.

To summarize:

1. An object's identity hash is a 21 or 22 bits random number (on 32 and 64 bits architectures respectively)

2. Per the Birthday Paradox, that means the chance of a collision is > 50% with approx. 1700 or 2400 objects.

You can use it to store objects in a hashmap but you need to additionally check with a.same_value(b) if the object already exists in the hashmap bucket.

from rusty_v8.