"containing" memory-consuming computations

[Simon Marlow]

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 
reachable.

Cheers,
	Simon