[GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory
GHC
ghc-devs at haskell.org
Thu Oct 16 04:39:38 UTC 2014
#9696: readRawBufferPtr and writeRawBufferPtr allocate memory
-------------------------------------+-------------------------------------
Reporter: mergeconflict | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.3
Keywords: | Operating System:
Architecture: x86_64 (amd64) | Unknown/Multiple
Difficulty: Unknown | Type of failure: Runtime
Blocked By: | performance bug
Related Tickets: | Test Case:
| Blocking:
| Differential Revisions:
-------------------------------------+-------------------------------------
I initially filed this as a [http://stackoverflow.com/questions/26333815
/why-do-hgetbuf-hputbuf-etc-allocate-memory question on StackOverflow],
assuming that the behavior I'm seeing was intentional, or that I was
misinterpreting the profiler results... but Kazu Yamamoto
[https://twitter.com/kazu_yamamoto/status/522583112249663488 suggested] I
should file this as an issue here. It's my first GHC ticket, so here goes:
{{{#!hs
main :: IO ()
main = do
buf <- mallocArray 1
echo buf
echo :: Ptr Word8 -> IO ()
echo buf = forever $ do
len <- readRawBufferPtr "read" stdin buf 0 1
writeRawBufferPtr "write" stdout buf 0 (fromIntegral len)
}}}
I expect the only heap allocation here should be my explicit
`mallocArray`, but profiling with `+RTS -P` indicates this isn't the case:
both the read and write operations do appear to allocate some short-lived
heap objects. In contrast:
{{{#!hs
echo :: Ptr Word8 -> IO ()
echo buf = forever $ do
threadWaitRead $ Fd 0
len <- c_read 0 buf 1
c_write 1 buf (fromIntegral len)
yield
}}}
does not appear to allocate.
I did a bit of digging (copying bits of source code from `base` into my
own project, to get cost center annotations) and it seems like the
allocation might be happening in `throwErrnoIfRetryMayBlock`. See
[https://gist.github.com/anonymous/3ba3cfa118e1d05870d4 this gist] for
more detail, including core output from `-ddump-simpl`.
In all honesty, I don't know whether this is a bug. I was just surprised
by it, when I first encountered it using `hGetBuf` / `hPutBuf`, so I'm
trying to understand whether this is expected behavior and why.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9696>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list