Behavior of touch#

Simon Peyton Jones simonpj at microsoft.com
Tue Dec 16 09:00:10 UTC 2014


Would it make sense to elaborate the Haddock docs to explain stuff here?

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Carter Schonwald
Sent: 16 December 2014 06:45
To: Brandon Simmons
Cc: glasgow-haskell-users
Subject: Re: Behavior of touch#

https://github.com/ghc/ghc/blob/8c10b67ba049477cc9ed23e61f5bd119e1cefc29/compiler/cmm/CmmMachOp.hs#L556

and https://github.com/ghc/ghc/blob/8c10b67ba049477cc9ed23e61f5bd119e1cefc29/compiler/nativeGen/X86/CodeGen.hs#L1731

spell it out a bit more

so touch is preserved through the CMM level, and then gets erased when doing final code gen.
Its meant to ensure on heap pointers remain reachable

On Tue, Dec 16, 2014 at 1:43 AM, Carter Schonwald <carter.schonwald at gmail.com<mailto:carter.schonwald at gmail.com>> wrote:
the point of touch is to prevent premature GC, it actually gets erased at the CMM level i believe.
That is, it only makes sense to apply touch to lifted types on the heap!

On Mon, Dec 15, 2014 at 4:21 PM, Brandon Simmons <brandon.m.simmons at gmail.com<mailto:brandon.m.simmons at gmail.com>> wrote:
The `primitive` package exports a lifted version of the undocumented `touch#`

    http://hackage.haskell.org/package/ghc-prim-0.3.1.0/docs/GHC-Prim.html

which has type:

    touch :: PrimMonad m => a -> m ()

I'd like to know if this works correctly in general, or will it suffer
from the same gotches w/r/t unboxing as with addFinalizer and Weak
references? i.e. must it only be passed an unboxed type?

Brandon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users at haskell.org<mailto:Glasgow-haskell-users at haskell.org>
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20141216/9758aa80/attachment-0001.html>


More information about the Glasgow-haskell-users mailing list