"containing" memory-consuming computations

Edward Z. Yang ezyang at MIT.EDU
Fri Apr 20 18:56:25 CEST 2012


So, it would be pretty interesting if we could have an ST s style
mechanism, where the data structure is not allowed to escape.
But I wonder if this would be too cumbersome for anyone to use.

Edward

Excerpts from Simon Marlow's message of Fri Apr 20 06:07:20 -0400 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 
> reachable.
> 
> Cheers,
>     Simon
> 



More information about the Glasgow-haskell-users mailing list