Why does System.Type.GetHashCode return the same value for all instances and types?

Question

The following code produces the output of 46104728:

using System;  namespace TestApplication {     internal static class Program     {         private static void Main()         {             Type type = typeof(string);             Console.WriteLine(type.GetHashCode());             Console.ReadLine();         }     } } 

But so does this:

using System;  namespace TestApplication {     internal static class Program     {         private static void Main()         {             Type type = typeof(Program);             Console.WriteLine(type.GetHashCode());             Console.ReadLine();         }     }  } 

Yet on http://ideone.com it produces varying results for each type. This issue has been reproduced on more than one system now. I'm using .NET 4.0 right now.

Answer 1

You've run into what you believe to be a problem, however, if you were to look at their hash codes in the same execution you'll find that they're not identical but instead rely on their order of usage:

Console.WriteLine("{0} {1:08X}", typeof(string), typeof(string).GetHashCode()); Console.WriteLine("{0} {1:08X}", typeof(Program), typeof(Program).GetHashCode()); // System.String 02BF8098 // Program 00BB8560 

If I run that same program again, swapping their order:

Console.WriteLine("{0} {1:08X}", typeof(Program), typeof(Program).GetHashCode()); Console.WriteLine("{0} {1:08X}", typeof(string), typeof(string).GetHashCode()); // Program 02BF8098 // System.String 00BB8560 

This is a non-issue at runtime as the returned values do not violate the rules for implementing Object.GetHashCode.

But, as you noted this behavior seems curious!

I delved into the source and found the implementation of Type.GetHashCode is foisted off onto MemberInfo.GetHashCode, which is again foisted off onto Object.GetHashCode which calls RuntimeHelpers.GetHashCode(this).

It is at this point that the trail goes cold, however, my assumption is the inner workings of that method creates a new value, mapped per instance, based on the order of calls.

I tested this hypothesis by running the same code above with two instances of Program (after adding a property to identify them):

var b = new Program() { Name = "B" }; var a = new Program() { Name = "A" }; Console.WriteLine("{0} {1:08X}", a.Name, a.GetHashCode()); Console.WriteLine("{0} {1:08X}", b.Name, b.GetHashCode()); // A 02BF8098 // B 00BB8560 

Thus, for classes which do not explicitly override Object.GetHashCode, instances will be assigned a seemingly predictable hash value based on the order in which they call GetHashCode.

---

Update: I went and looked at how Rotor/Shared Source CLI handles this situation, and I learned that the default implementation calculates and stores a hash code in the sync block for the object instance, thus ensuring the hash code is generated only once. The default computation for this hash code is trivial, and uses a per-thread seed (wrapping is mine):

// ./sscli20/clr/src/vm/threads.h(938) // Every thread has its own generator for hash codes so that we // won't get into a situation where two threads consistently give // out the same hash codes. // Choice of multiplier guarantees period of 2**32 // - see Knuth Vol 2 p16 (3.2.1.2 Theorem A). 

So if the actual CLR follows this implementation it would seem any differences seen in hash code values for objects are based on the AppDomain and Managed Thread which created the instance.

Answer 2

Program (.NET 4, AnyCPU):

var st = typeof(string); var pt = typeof(Program); Console.WriteLine(st.GetHashCode()); Console.WriteLine(pt.GetHashCode()); Console.WriteLine(typeof(string).GetHashCode()); Console.WriteLine(typeof(Program).GetHashCode()); Console.ReadLine(); 

Run 1:

33156464 15645912 33156464 15645912 

Run 2-6:

45653674 41149443 45653674 41149443 

Run 7:

46104728 12289376 46104728 12289376 

Run 8:

37121646 45592480 37121646 45592480 

While I can understand the randomness as long as the hashcode is consistent during the program lifetime, it bothers me that it is not always random.