Received: by 10.180.103.135 with SMTP id fw7mr462560wib.4.1329295988251;
        Wed, 15 Feb 2012 00:53:08 -0800 (PST)
X-BeenThere: parallel-haskell@googlegroups.com
Received: by 10.180.146.202 with SMTP id te10ls734199wib.4.gmail; Wed, 15 Feb
 2012 00:53:07 -0800 (PST)
Received: by 10.216.139.141 with SMTP id c13mr1162809wej.4.1329295987041;
        Wed, 15 Feb 2012 00:53:07 -0800 (PST)
Received: by 10.216.139.141 with SMTP id c13mr1162808wej.4.1329295987026;
        Wed, 15 Feb 2012 00:53:07 -0800 (PST)
Return-Path: <marlo...@gmail.com>
Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180])
        by gmr-mx.google.com with ESMTPS id w7si1513762wid.1.2012.02.15.00.53.07
        (version=TLSv1/SSLv3 cipher=OTHER);
        Wed, 15 Feb 2012 00:53:07 -0800 (PST)
Received-SPF: pass (google.com: domain of marlo...@gmail.com designates 74.125.82.180 as permitted sender) client-ip=74.125.82.180;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of marlo...@gmail.com designates 74.125.82.180 as permitted sender) smtp.mail=marlo...@gmail.com; dkim=pass header...@gmail.com
Received: by mail-we0-f180.google.com with SMTP id l4so611838wer.11
        for <parallel-haskell@googlegroups.com>; Wed, 15 Feb 2012 00:53:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        bh=DIgzl6EEQhHbsy7FMhxbtXC3SiR41MbV1lWuvG8EkUE=;
        b=ZugJe9IQ24t/KZaLTg6olSewtSrawfvH4riPomGKI3nMwf1pQDO24hEDonk71PWqSy
         8CTHhOYdAwCdgU9kPbSv6q4JgPwx+npl7loqmH+OEY5IDaiel69irOQ/4gOztu5lzsIu
         OcqerMKMUuGuZKQrJMjVvL5jMxSs+C8yAeOWE=
Received: by 10.180.92.229 with SMTP id cp5mr33988215wib.8.1329295986847;
        Wed, 15 Feb 2012 00:53:06 -0800 (PST)
Return-Path: <marlo...@gmail.com>
Received: from [213.199.145.11] ([213.199.145.11])
        by mx.google.com with ESMTPS id er8sm7529857wib.1.2012.02.15.00.53.06
        (version=TLSv1/SSLv3 cipher=OTHER);
        Wed, 15 Feb 2012 00:53:06 -0800 (PST)
Message-ID: <4F3B7271.1090...@gmail.com>
Date: Wed, 15 Feb 2012 08:53:05 +0000
From: Simon Marlow <marlo...@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Duncan Coutts <duncan.cou...@googlemail.com>
CC: andreas.voel...@gmail.com, 
 parallel-haskell <parallel-haskell@googlegroups.com>
Subject: Re: Synchronizations in memory allocation?
References: <4a44b19c-6391-46a1-9743-94a0e47ec...@bs8g2000vbb.googlegroups.com> <CADdwyZmNWJE=beatv7BJRJx9xmsmejNOjLW-Vm1Q1_cy1ER...@mail.gmail.com> <4F38ECEB.10...@gmail.com> <CALBWgsM6px33RQh2WvtFpCyUsaBpqo5qPZwq+zvagg4QNrb...@mail.gmail.com>
In-Reply-To: <CALBWgsM6px33RQh2WvtFpCyUsaBpqo5qPZwq+zvagg4QNrb...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 13/02/2012 15:45, Duncan Coutts wrote:
> On 13 February 2012 10:58, Simon Marlow<marlo...@gmail.com>  wrote:
>
>> allocatePinned() gets new blocks from the global block allocator, which is
>> protected by a lock.  Obviously this lock is going to be pretty heavily
>> contended in your program.  The reason that newByteArray# scales better (or
>> less badly) is that it gets new blocks from the nursery rather than the
>> global block allocator, and the nursery is a purely local data structure.
>>
>> So I changed allocatePinned() to work in the same way as allocate(), and
>> observed a nice improvement in your benchmark.
>
> How do you allocate pinned memory from the nursary? I didn't think
> that was possible with the current heap / GC design. I remember some
> more flexible stuff from the local heaps paper, but I didn't think
> that was being used yet.

Duncan & I talked about this on IRC, but to summarise for other members 
of the list: the change I made is for the pinned memory allocator to 
steal complete blocks from the nursery rather than allocating them from 
the global block allocator, thus avoiding a lock on this code path. 
Since it is only stealing complete blocks, there is no issue with 
intermingling pinned and unpinned objects in the same block, which is 
something GHC's memory manager doesn't currently support.

The pinned memory allocator can now empty the nursery, and the GC will 
then have to refill the nursery by allocating new blocks to replace the 
stolen ones.  Overall, it seems to be a win to do it this way though.

Cheers,
	Simon