"containing" memory-consuming computations
marlowsd at gmail.com
Fri Apr 20 12:07:20 CEST 2012
On 19/04/2012 11:45, Herbert Valerio Riedel wrote:
> For the time-dimension, I'm already using functions such as
> System.Timeout.timeout which I can use to make sure that even a (forced)
> pure computation doesn't require (significantly) more wall-clock time
> than I expect it to.
Note that timeout uses wall-clock time, but you're really interested in
CPU time (presumably). If there are other threads running, then using
timeout will not do what you want.
You could track allocation and CPU usage per thread, but note that
laziness could present a problem: if a thread evaluates a lazy
computation created by another thread, it will be charged to the thread
that evaluated it, not the thread that created it. To get around this
you would need to use the profiling system, which tracks costs
independently of lazy evaluation.
On 19/04/2012 17:04, Herbert Valerio Riedel wrote:
>> At least this seems easier than needing a per-computation or
>> per-IO-thread caps.
> How hard would per-IO-thread caps be?
For tracking "memory use", which I think is what you're asking for, it
would be quite hard. One problem is sharing: when a data structure is
shared between multiple threads, which one should it be charged to? Both?
To calculate the amount of memory use per thread you would need to run
the GC multiple times, once per thread, and observe how much data is
reachable. I can't think of any fundamental difficulties with doing
that, but it could be quite expensive. There might be some tricky
interactions with the reachability property of threads themselves: a
blocked thread is only reachable if the object it is blocked on is also
More information about the Glasgow-haskell-users