I have not been following the details of this, I’m afraid, but I notice this:

> forever' m = do _ <- m
>                 forever' m

When I define that version of forever, the space leak goes away.

What was the old version of forever that led to the leak?

If you can boil down the leak to a simple test case, do submit a Trac ticket.

Simon

From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Jason Dagit
Sent: 14 April 2010 22:50
To: Gregory Collins
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] GHC, odd concurrency space leak

On Wed, Apr 14, 2010 at 2:44 PM, Jason Dagit <dagit@codersbase.com> wrote:

On Wed, Apr 14, 2010 at 2:13 PM, Gregory Collins <greg@gregorycollins.net> wrote:

Jesper Louis Andersen <jesper.louis.andersen@gmail.com> writes:

> This post describes some odd behaviour I have seen in GHC 6.12.1 when writing
> Combinatorrent. The post is literate Haskell so you can run it. The executive
> summary: A space leak occurs when a new process is spawned from inside another
> process - and I can't figure out why. I am asking for help on haskell-cafe.
>

> ...[snip]...
>>
>> import Control.Monad.State

Does the problem go away if you use "Control.Monad.State.Strict"?

Nope :)  That was the first thing I tried here.

I tried playing with optimization level too.

Next I tried making two versions that were as similar as possible and then comparing the core with ghc-core.  I can't see a difference between a version that uses 1MB and a version that uses 160MB (on my system 160MB is the worst I can get it to blow up).

The two versions I compared:
Low memory:
\begin{code}
> startp4 :: IO ThreadId
> startp4 = spawn () () (return ())

> startp3 :: IO ThreadId
> startp3 = spawn () () (forever $
>                        do liftIO startp4
>                           liftIO $ putStrLn "Delaying"
>                           liftIO $ threadDelay (3 * 1000000))

> main1 = do
>   putStrLn "Main thread starting"
>   startp3
>   threadDelay (1 * 1000000)
>
> main = main1
\end{code}

Too much memory:
\begin{code}
> startp4 :: IO ThreadId
> startp4 = spawn () () (forever $ return ())

> startp3 :: IO ThreadId
> startp3 = spawn () () (forever $
>                        do liftIO startp4
>                           liftIO $ putStrLn "Delaying"
>                           liftIO $ threadDelay (3 * 1000000))

> main1 = do
>   putStrLn "Main thread starting"
>   startp3
>   threadDelay (1 * 1000000)
>
> main = main1
\end{code}

The difference is whether or not the threads must keep returning () or if they returns it once.

I'm not sure what to make of it.  My conclusion is that keeping the thread alive via forever is the problem, but when I test this hypothesis with a threadDelay the space leak goes away:

\begin{code}
> startp4 :: IO ThreadId
> startp4 = spawn () () (liftIO $ threadDelay (100 * 1000000))

> startp3 :: IO ThreadId
> startp3 = spawn () () (forever $
>                        do liftIO startp4
>                           liftIO $ putStrLn "Delaying"
>                           liftIO $ threadDelay (3 * 1000000))

> main1 = do
>   putStrLn "Main thread starting"
>   startp3
>   threadDelay (1 * 1000000)
>
> main = main1
\end{code}

It will be interesting to hear what fixes this!

> forever' m = do _ <- m
>                 forever' m

When I define that version of forever, the space leak goes away.