What does RuntimeHelpers.GetHashCode do

Question

The RuntimeHelpers.GetHashCode(object) method allows generating hash codes based on the identity of an object. MSDN states:

The RuntimeHelpers.GetHashCode method always calls the Object.GetHashCode method non-virtually, even if the object's type has overridden the Object.GetHashCode method.

[MethodImpl(MethodImplOptions.InternalCall)]
[SecuritySafeCritical]
public static extern int GetHashCode(object o);

However, when inspecting the Object.GetHashCode() method using Reflector (.NET 4.0), we'll see the following code:

public virtual int GetHashCode()
{
    return RuntimeHelpers.GetHashCode(this);
}

This makes me believe that the MSDN documentation is wrong, since calling Object.GetHashCode from within the RuntimeHelpers.GetHashCode(object) would cause a stack overflow.

So what is the actual behavior of RuntimeHelpers.GetHashCode(object) and how does it work? How does it calculate the hash?

@dtb there are some places where C# makes a non-virtual call to a virtual method - `base.*` for example. In most scenarios, using `call` on a virtual method will make the CLI shout loudly at you - it isn't allowed, *regardless* of the language of the caller. — Marc Gravell, Jun 28 '12 at 08:28

score 29 · Accepted Answer · edited Oct 21 '18 at 10:33

29

I think the MSDN documentation is trying to describe the behaviour, not the implementation. The key point: RuntimeHelpers returns the default implementation that you would get were object.GetHashCode() not overridden.

This is really useful if, for example, you want to build a reference equality lookup, even for types that have overridden Equals and GetHashCode. I do this in a serializer that I maintain, using RuntimeHelpers.GetHashCode() and Object.ReferenceEquals.

edited Oct 21 '18 at 10:33

jacekbe

499
1
5
18

answered Jun 28 '12 at 07:39

Marc Gravell

1,026,079
266
2,566
2,900

So, the documentation is a bit misleading, or am I just interpretering it incorrectly? – Steven Jun 28 '12 at 07:42
1

@Steven yes, saying that it "calls the Object.GetHashCode method non-virtually" is a bit misleading, especially given the two other implementations shown here (in your post, and "Me.Name"'s post) – Marc Gravell Jun 28 '12 at 07:44
@Jon *yes*, but based on the two reflector dumps in this post and one of the answers, it isn't actually how the IL is implemented. – Marc Gravell Jun 28 '12 at 07:45
@MarcGravell: Yes, and I'm going to elaborate on that in my answer instead of in comments :) – Jon Skeet Jun 28 '12 at 07:45
@Jon I shall look forward to it ;p – Marc Gravell Jun 28 '12 at 07:46
"you want to build a reference equality lookup". And guess what, that's what I'm trying to do ;-) – Steven Jun 28 '12 at 07:46
I guess there is a typo. It should be RuntimeHelpers instead of RuntimeTypeHelpers – jacekbe Oct 17 '18 at 17:00

Jon Skeet · Answer 2 · 2014-04-23T17:43:37.983

The point is that object.GetHashCode() can be overridden - and frequently is, e.g. by string. That means you can't find out the "identity hash code" which the default implementation of object.GetHashCode() returns.

This can be useful if you want to implement an equalty comparer (e.g. for a HashSet) which only considers object identity.

For example:

public class IdentityComparer<T> : IEqualityComparer<T> where T : class
{
    public bool Equals(T x, T y)
    {
        // Just for clarity...
        return object.ReferenceEquals(x, y);
    }

    public int GetHashCode(T x)
    {
        // The nullity check may be unnecessary due to a similar check in
        // RuntimeHelpers.GetHashCode, but it's not documented
        return x == null ? 0 : RuntimeHelpers.GetHashCode(x);
    }
}

Then:

string x = "hello";
string y = new StringBuilder("h").Append("ello").ToString();
Console.WriteLine(x == y); // True (overloaded ==)
Console.WriteLine(x.GetHashCode() == y.GetHashCode()); // True (overridden)

IdentityComparer<string> comparer = new IdentityComparer<string>();
Console.WriteLine(comparer.Equals(x, y)); // False - not identity

// Very probably false; not absolutely guaranteed (as ever, collisions
// are possible)
Console.WriteLine(comparer.GetHashCode(x) == comparer.GetHashCode(y));

EDIT: Just to clarify a bit...

So what is the actual behavior of RuntimeHelpers.GetHashCode(object) and how does it work?

The observed behaviour is that the value returned from RuntimeHelpers.GetHashCode(object) is the same as the value which would be returned from a non-virtual call to Object.GetHashCode(). (You can't write that non-virtual call in C# easily.)

As for how it works - that's an implementation detail :) It doesn't really matter IMO which way round things occur (what calls what). The important thing is the documented behaviour, which is correct. Heck, different versions of mscorlib could implement this differently - it wouldn't matter at all from a user's point of view. Without decompilation, you shouldn't be able to tell the difference.

It would (IMO) have been far more confusing for Object.GetHashCode to have been documented in terms of RuntimeHelpers.GetHashCode().

RuntimeHelpers.GetHashCode handles null, so there is no need to do it explicitly. — Matt Smith, Apr 23 '14 at 17:37
@MattSmith: Hmm... unfortunately that's not documented as far as I can see, so I wouldn't want to rely on it - but I'll add a comment. — Jon Skeet, Apr 23 '14 at 17:42
Good point. I actually considered it "documented" since normally Microsoft's documentation includes a clause in the documentation when it does throw (for example: System.ArgumentNullException: o is null.). But perhaps they are not always diligent. — Matt Smith, Apr 23 '14 at 18:03
@MattSmith in fact `object.GetHashCode()` handles null returning 0 too, if you're using a language that lets you non-virtually call an instance method on a null instance. (AFAIK, for all implementations out there). Of course, C# isn't such a language. — Jon Hanna, Nov 10 '16 at 21:16

score 4 · Answer 3 · edited Jun 28 '12 at 07:57

4

Strange, when I look at System.Object.GetHashCode via Reflector I see

public virtual int GetHashCode()
{
    return InternalGetHashCode(this);
}

and for runtimehelper:

public static int GetHashCode(object o)
{
    return object.InternalGetHashCode(o);
}

Perhaps it's a framework difference? I'm looking at 2.0 assemblies.

edited Jun 28 '12 at 07:57

Steven

166,672
24
332
435

answered Jun 28 '12 at 07:39

Me.Name

12,259
3
31
48

2

Don't remove this answer. It shows that the implementation can vary, but the behavior is still as specified. (Your answer was mentioned in Skeet's answer). – Jeppe Stig Nielsen Jun 28 '12 at 07:56

score 0 · Answer 4 · answered Jun 28 '12 at 07:40

0

From your own question, it looks like RuntimeHelpers.GetHashCode(Object) is really the implementation of the non-overridden Object.GetHashCode().

answered Jun 28 '12 at 07:40

Jeppe Stig Nielsen

60,409
11
110
181

What does RuntimeHelpers.GetHashCode do

4 Answers4

Linked