whitehole_spin: always 0?
It seems that the value of the whitehole_spin counter (as viewable by +RTS -s) is always zero, which oddly suggests that there is never any contention on the particular atomic operation whitehole_spin is tracking (located in copyPart in Evac.c). This may be a symptom of a bug, or it may be the case that the atomic operation is not necessary. (Or perhaps contention is just very rare. But if contention is rare, why is this operation being counted in particular?) Either way, I think this is a bit strange and probably worth investigating. Patrick
Looks like whitehole_spin is _not_ always 0. Contention just seems to be
really rare.
On Thu, Jul 25, 2013 at 1:32 PM, Patrick Palka
It seems that the value of the whitehole_spin counter (as viewable by +RTS -s) is always zero, which oddly suggests that there is never any contention on the particular atomic operation whitehole_spin is tracking (located in copyPart in Evac.c). This may be a symptom of a bug, or it may be the case that the atomic operation is not necessary. (Or perhaps contention is just very rare. But if contention is rare, why is this operation being counted in particular?) Either way, I think this is a bit strange and probably worth investigating.
Patrick
Excerpts from Patrick Palka's message of Fri Jul 26 14:21:11 -0700 2013:
Looks like whitehole_spin is _not_ always 0. Contention just seems to be really rare.
I think the paper "Parallel Generational-Copying Garbage Collection with a Block-Structured Heap" can give some intuition on why contention is low. Edward
Thanks! That was a very informative read.
On Fri, Jul 26, 2013 at 5:31 PM, Edward Z. Yang
Excerpts from Patrick Palka's message of Fri Jul 26 14:21:11 -0700 2013:
Looks like whitehole_spin is _not_ always 0. Contention just seems to be really rare.
I think the paper "Parallel Generational-Copying Garbage Collection with a Block-Structured Heap" can give some intuition on why contention is low.
Edward
participants (2)
-
Edward Z. Yang -
Patrick Palka