On 16 December 2005 12:42, Joel Reymont wrote:
On Dec 16, 2005, at 12:36 PM, Simon Marlow wrote:
If script#9 is the cost center attached to all of your leaking heap data, then you're already a long way to finding the problem. It'll help even more to find out whether it is just unevaluated copies of "takeEmptySeat Holdem affid []", or something else (-hd, -hy will help here). Try +RTS -hy -hcscript#9, for example.
One obvious thing to try is replacing the '$' before {-# SCC "script#9" #-} with '$!'. And similarly in takeEmptySeat.
Let me try these and report my findings.
(I should say that we definitely plan to update these for STM, but it's not completely trivial (I checked). Volunteers definitely welcome).
I volunteer! Just need some pointers on where to get started. I learn quickly but need to be guided ;-). Plus, I need this the most, right?
I was slightly mistaken: lag/drag/void profiling is pretty easy. Take a look at ghc/rts/LdvProfile.c and add relevant cases for STM objects to processHeapClosureForDead(). If you fix this up and test it we should be able to get it into 6.4.2. Retainer profiling is much harder; the code is in RetainerProfile.c/RetainerSet.c. Cheers, Simon