[ghc-steering-committee] Replace atomicModifyMutVar# (#149), recommendation: accept

[Simon Marlow]

On 5 July 2018 at 16:24, Simon Peyton Jones <simonpj at microsoft.com> wrote:

> It sounds good to me – I have not dug into the details but it seems to
> have had enough scrutiny.
>
>
>
> Note that it *replaces one primop with another*, with the old one being
> re-defined as an ordinary function for back-compat.   The proposal does not
> just add an extra primop.  Right?
>
>
Yes, that's right.

Simon


>
>
> I’m supportive, albeit not very well informed.
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Simon Marlow
> *Sent:* 04 July 2018 10:19
> *To:* ghc-steering-committee at haskell.org
> *Subject:* [ghc-steering-committee] Replace atomicModifyMutVar# (#149),
> recommendation: accept
>
>
>
> https://github.com/ghc-proposals/ghc-proposals/pull/149
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F149&data=02%7C01%7Csimonpj%40microsoft.com%7Caf6991e741df405fd5a308d5e18f477f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636662927862631135&sdata=biPMT2Nj9w7jJHUSdHU3eaHMS9wOzIbm7w%2B6txXLpeE%3D&reserved=0>
>
>
>
> This proposal is essentially an optimisation to the atomicModifyMutVar#
> primitive. I won't repeat the details here, but it amounts to moving one of
> the thunks produced by atomicModifyMutVar# out of the primop and into the
> atomicModifyIORef wrapper. The advantage is that in the case of the strict
> version of the wrapper, atomicModifyIORef', this extra thunk is eliminated
> entirely, rather than being created by the primop and then immediately
> evaluated by the wrapper.
>
>
>
> I propose we accept the proposal to add the new primop in section 2.1,
> along with the straightforward additions proposed in sections 2.2 and 2.3.
> (the old primop will be removed, but can be defined in GHC.Exts  as a
> wrapper around the new primop for backwards compat)
>
>
>
> However, the additions to the Data.IORef library should be considered by
> the libraries committee separately. (there are naming issues to be resolved
> in particular).
>
>
>
> Cheers
>
> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20180705/b30ec3fd/attachment.html>