GC behavior when pinning an object

for (int i = 0; i < m_restockSize; i++)
{
// Make a new buffer.
object newBuffer = m_factory();

// Create space between the objects. We do this because otherwise it forms
// a single plug (group of objects) and the GC pins the entire plug making
// them NOT move to Gen1 and Gen2. By putting space between them
// we ensure that object get a chance to move independently (even if some are pinned).
var dummyObject = new object();
m_NotGen2.Add(newBuffer);
}

It got me wondering what the reference to a plug means? While trying to pin an object in memory, wouldn't the GC pin the specific address specified for the object? What is this

plug

behavior actually doing and why is there a need to "space out" between the objects?

Ok, so after several attempts to get official replies from people with "inside knowledge", I decided to experiment a little myself.

What I tried to do is re-produce the scenario where I have a couple of pinned objects and some unpinned objects between them (i used a byte[]) to try and create the effect where the unpinned objects don't move the a higher generation inside the GC heap.

The code ran on my Intel Core i5 laptop, inside a 32bit console application running Visual Studio 2015 both in Debug and Release. I debugged the code live using WinDBG.

And I see they have all stayed at the same address. But, the fact that generation 0 now starts at 0x02547524 means they've all been promoted to generation 1.

Then, I remember reading something about that behavior in the book Pro .NET Performance, it states the following:

Pinning an object prevents it from being moved by the garbage
collector. In the generational model, it prevents promotion of pinned
objects between generations. This is especially significant in the
younger generations, such as generation 0, because the size of
generation 0 is very small. Pinned objects that cause fragmentation
within generation 0 have the potential of causing more harm than it
might appear from examining pinned before we introduced generations
into the the picture. Fortunatly, the CLR has the ability to promote
pinned objects using the following trick: if generation 0 becomes
severely fragmented with pinned objects, the CLR can declare the
entire space of generation 0 to be considered a higher generation and
allocate new objects from a new region of memory that will become
generation 0. This is achieved by changing the ephemeral segment.

And this actually explains the behavior i'm seeing inside WinDBG.

So, to conclude and until anyone has any other explanation, I think the comment isn't correct and doesn't really capture what is really happening inside the GC. If anyone has anything to elaborate, I'd be glad to add.