[grapefruit] growing heap usage

[Neal Alexander]

Hey,

I still need to figure out which branches Simon Marlow committed the GC 
changes to and retest things. Its gonna be like 6 weeks until i have 
time to play with it again though.

Anyway, I'm not sure what the recommended way of splitting profile data 
into smaller bands is. I usually just split a function up into several 
top level functions so each section gets an entry in the profilers 
output. IIRC you can do this for library code too, by making a wrapper 
function for it.

Btw i noticed some situations where signals can get lost (due to 
starvation and time-out with concurrency primitives maybe?). I need to 
look into it more since i forgot the details, but the basic setup was:
1 render thread generating discrete frame events nonstop
2 human inputs generating discrete signals asynchronously

If the render thread is allowed to loop without Vsync or anything 
blocking it the signals attached to human inputs seem to get lost. 
Adding a threadDelay 500 to the render loop fixes it. If i had to take a 
  wild guess: maybe something is trying to use a spinlock that times out 
and quits after a certain amount of time spent trying to acquire the lock.



Wolfgang Jeltsch wrote:
> Am Mittwoch, 22. Juli 2009 03:43 schrieb Neal Alexander:
>>  > Do you know when the garbage collector starts collecting garbage?
>>
>> It collects several times per second according to the +RTS -S messages.
>>
>> And btw, I think something might be wrong with the GC, maybe its
>> accumulating statistics even when profiling is disabled, or theres
>> something going on with the FFI call to performGC.
>>
>> With the program:
>>
>> main = forever $ performGC
>>
>> The OS reported memory usage grows fast. If i enable +RTS -S the GC
>> statistics show the heap "live bytes" being constant.
> 
> Hello Neal,
> 
> I saw your post on haskell-cafe and the answer from Simon Marlow. So there 
> seems to be a bug on Windows which is fixed now. However, I’m not sure 
> whether this fixes the problem with Grapefruit and garbage collection 
> completely since I experienced problems also on Linux.
> 
> I’m not having the time at the moment to do experiments using my insufficient 
> profiling skills. So could you please assist me a bit? As I told you, heap 
> profiling always gave me a single band for 
> Internal.Signal.Discrete.Vista.CAF. How can I split this monolithic band into 
> smaller ones that let me see where exactly the space is being leaked?
> 
> Best wishes,
> Wolfgang
> 
> _______________________________________________
> Grapefruit mailing list
> Grapefruit at projects.haskell.org
> http://projects.haskell.org/cgi-bin/mailman/listinfo/grapefruit