Reveal synchronized block index (bottom): summary

Before, I used two articles to discuss in detail the role of the Synchronized block index in lock and GetHashCode. However, two articles are discussed separately. That may be asked if I have an object, it both as a lock Lockhelper object, but also to call its GetHashCode method to do, is this synchronized block index can assume these two tasks. The Synchronized block index can assume both tasks, but there is a bigger secret inside, so let's take a look at the structure associated with the Synchronized block index:

This is roughly the structure in which a syncblockindex in the Objectheader of an object points to an item in a Sync block Entry table, which is indicated by a dotted line, indicating that it is not pointing directly to a pointer, but an index, What is the advantage of this is that the CLR can place the table wherever it is, or increase the capacity of the table on demand anyway, I'm using the index instead of the pointer, which is an indirect point. Each item in this table is a synctableentry, this synctableentry has two fields, the first field is a syncblock pointer, pointing to a SyncBlock object. There is also a field that is an object pointer, and with this pointer the CLR can track which object the SyncBlock is, and Synctableentry and SyncBlock are not in the GC-managed memory, so can be based on this object* To track an instance of the corresponding object, and when the object is dead, the corresponding SyncBlock and synctableentry can be reclaimed, but the pointer to this object is a weak reference (the weak reference is that if there is no strong reference to the object, the object can be considered garbage. Allowed to be garbage collected).

Note, however, that the above structure is not an object "innate", which means that the object is not the same when it is first initialized. When an object is just initialized, in Objectheader, the Syncblockindex field is 0, as we have seen in the visual Studio + SOS experiment in the previous article. If the GetHashCode method of the object is invoked, the lower 26 bits of the Syncblockindex field in the Objectheader of the object are used to store the hashcode of the object, and the height of 6 bits as an identity, This means that Syncblockindex is now used as a storage hashcode, with the Syncblockindex and Bit_sblk_is_hashcode (#define Bit_sblk_is_hashcode 0x04000000) to do or operation, discriminant of the time to do and operation. This is also introduced in the previous article. And if you call the object's GetHashCode method, do you continue to use the object as a lock object? This time Syncblockindex's 26-bit low will turn into an index, and also Bit_sblk_is_hash_or_syncblkindex (#define Bit_sblk_is_hash_or_ Syncblkindex 0x08000000) To do or operation, that this syncblockindex now AH has the function of storing hashcode, but also as the object of lock.

So since the low 26 has become an index, where has the original hashcode gone? This will be a probe into the structure of the SyncBlock: