"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.
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
More information about the Glasgow-haskell-users