[Haskell-cafe] Data.Map and strictness (was: Is Haskell a Good Choice for WebApplications?(ANN: Vocabulink))

[Tim Docker]

Actually, I'm unsure how to fix this. For an expression like this:

    Data.Map.delete key map

how can I use seq (or something else) to sufficiently evaluate the above
to ensure that the value associated with key can be garbage collected?
My
knowledge of Data.Map is limited to it's haddock documentation.


-----Original Message-----
From: haskell-cafe-bounces at haskell.org
[mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Tim Docker
Sent: Thursday, 7 May 2009 6:04 PM
To: haskell-cafe at haskell.org
Subject: RE: [Haskell-cafe] Is Haskell a Good Choice for
WebApplications?(ANN: Vocabulink)

I think that multi-threading in combination with laziness makes space
usage harder to manage. In fact, just today I have discovered a problem
with a long running server process with a subtle space leak.

With a regular process that communicates with the outside world via IO,
I know that the act of communicating a value causes it to be fully
evaluated. However, with a multi threaded process, communication occurs
via writes to TVars/IOVars and nothing gets evaluated. This gives lots
of opportunities for space leaks. In this particularly case cleanup code
was removing a large entry from a map stored in a Tvar. Because that map
is only read infrequently, however, the memory release is delayed.

This is the second such problem I've found. The profiling tools do help
in discovering them, but it still needs a bit of thought and analysis. I
wonder if, for my application, I should work out some means of
deepseqing every value written to a Tvar.

Tim

-----Original Message-----
From: haskell-cafe-bounces at haskell.org
[mailto:haskell-cafe-bounces at haskell.org] On Behalf Of wren ng thornton
Sent: Thursday, 7 May 2009 2:06 PM
To: haskell-cafe at haskell.org
Subject: Re: [Haskell-cafe] Is Haskell a Good Choice for Web
Applications?(ANN: Vocabulink)

FFT wrote:
> Anton van Straaten wrote:
> 
> > The app is written for a client under NDA, so a blog about it would 
> > have to be annoyingly vague.
> 
> > No doubt the potential for encountering space leaks goes up as one 
> > writes less pure code, persist more things in memory, and depend on
more libraries.
> 
> Exactly. I'm worried about, e.g. needing to use something as simple as

> a stream of prime numbers (see the recent thread about leaks there)

The issues here are going to be the same in Haskell as in every other
language. There's always a tradeoff between the memory of caching old
results vs the time of recalculating them. At present no language's
RTS/GC is smart enough to make that tradeoff for you, and so memoization
must be done manually.

There are some tricks to help make this easier (e.g. weak pointers), but
the problem will always remain. The only thing that makes this perhaps
trickier than in other languages is that, AFAIK/R, the reflection API to
ask the RTS how it's feeling about memory at any given point isn't
terribly portable (between Haskell compilers) or polished/pretty. Then
again, the other GC languages I've dealt with aren't much better and are
often worse.

--
Live well,
~wren
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe