```
class MyClass(object):
    pass

a = MyClass()
a.obj = a
del a
```

4: mutator allots a block from free memory for a with epoch. a = 2
5: a.obj = a. This makes mutator to have a = 3, and marker brings a from root set to be set to 3(from the prev cycle).
However, a refers to a with epoch = 3. So, it is a cycle. both a.obj and a are in the root set.
6: del a. This does not delete a from root set, it just deletes a from the context of current stack in code. a.obj refers to a and both of them are at epoch 3.

So, in the current stack of this module, even as the code proceeds, the sweeper would never be able to free the
a's memory blocks as they will be in the root set with epoch's color because marker would keep bringing the reachable data from root set "up to date".
Reference from the paper:
>The sweeper thread is parameterized by COLOR(epoch-2),
>called the sweeper color (line g in Figure 1). It examines every block of storage in the system. If block b has
>sweeper color it may be deallocated and returned to the
>free list; reclamation of b is safe because neither the mutator nor marker can reach it. If b has COLOR(epoch) or
>COLOR(epoch-1), it is skipped because it is still potentially
>in use. (Blocks with marker color (COLOR(epoch-1)) will
>either be marked with COLOR(epoch) during this epoch if
>reachable from the root set or their color remains unchanged,
>indicating that they have become garbage. Garbage thus
>identied will be detected by the sweeper in the next epoch.)
>It is simple matter for an implementation to make reclaimed
>free lists available for mutator allocation without explicit
>synchronization (x4).

So, the condition mentioned above states that the object's block will be freed if its color is epoch-2 and unreachable from the marker and mutator.
In this case, it will always be epoch, updated by marker. Hence, never freed.