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

[Simon Peyton Jones]

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?

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/c16d1444/attachment.html>