[GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory

GHC ghc-devs at haskell.org
Thu Oct 16 07:25:32 UTC 2014


#9696: readRawBufferPtr and writeRawBufferPtr allocate memory
-------------------------------------+-------------------------------------
              Reporter:              |            Owner:
  mergeconflict                      |           Status:  new
                  Type:  bug         |        Milestone:
              Priority:  normal      |          Version:  7.8.3
             Component:  Compiler    |         Keywords:
            Resolution:              |     Architecture:  x86_64 (amd64)
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:  Runtime     |  Related Tickets:
  performance bug                    |
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------
Description changed by mergeconflict:

Old description:

> 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.

New description:

 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 each time through the loop. (Note: this isn't a space leak,
 the allocated objects appear to be GC'ed quickly, whatever they are). 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#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list