It is rising popularity of functional languages due to effective way to utilize multi-core CPUs (because immutability invariant provide some guarantees that allow some optimization) but are there any benefits to garbage-collector performance from immutability?
UPDATE During my search I found only one argument - possibility to avoid write barrier in GC algorithm (on sweep stage only, when GC at compat/defragmentation stage we still need write barrier, but that happen not often).
In absence of pointer comparison immutable objects can be passed by value and thus their heap-allocation may not be necessary if they can live on the stack or embedded in other objects. By eliminating them as referenceable objects you eliminate references that the GC has to traverse.
With pointer comparison immutable objects still force a programming style that can be more friendly to escape analysis / automatic stack allocation for some instances.
Additionally immutable objects also remove the need for defensive copying of which may be necessary when returning mutable data in a public interface.
While I am still search for benefits I found some arguments against performance to work with immutable objects.
Bergi suggest investigate Haskel memory model. Here immutability require creation of enormous number of new objects so there are a lot of work for GC, while it faster but amount of job also larger.
I also found another arguments against immutable structure here (while it not directly related to GC but related to most impotent data structure):
http://concurrencyfreaks.blogspot.com/2013/10/immutable-data-structures-are-not-as.html
Article show example of big tree that fit L2 CPU cache. Any mutable tree after modification require only 1 node insertion/deletion. Any imutalbe tree implementation require O(log(N)) nodes insertion/deletion into L2 cache. That may greatly reduce performance on tree structures.