#3094: Some GHC.* module should export word size and heap object header size
-----------------------------+----------------------------------------------
Reporter: duncan | Owner:
Type: bug | Status: new
Priority: normal | Component: libraries (other)
Version: 6.10.1 | Severity: normal
Keywords: | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-----------------------------+----------------------------------------------
Some code, like `bytestring`, uses magic constants to help it decide how
much memory to allocate. This is not a correctness issue, just an
optimisation one. It allows the `bytestring` package to allocate buffers
that make optimal use of ghc's pinned allocator strategy which has to use
a whole number of 4k pages. The magic is in subtracting the heap object
header size:
{{{
-- | Currently set to 32k, less the memory management overhead
defaultChunkSize :: Int
defaultChunkSize = 32 * k - chunkOverhead
where k = 1024
-- | Currently set to 4k, less the memory management overhead
smallChunkSize :: Int
smallChunkSize = 4 * k - chunkOverhead
where k = 1024
-- | The memory management overhead. Currently this is tuned for GHC only.
chunkOverhead :: Int
chunkOverhead = 2 * sizeOf (undefined :: Int)
}}}
This works for normal builds but for profiling builds it is a couple words
off which wastes memory. It would also be be nice if it did not have to
use magic constants but if it could import them from `GHC.Exts` or
something.
We would want:
* Heap object header size, in words (currently 2 normally or 4 for
profiling)
* Word size (4 or 8 bytes)
* Heap block size (currently 4k)
These should all be actual Haskell constants so that they inline perfectly
into calculations with no runtime overhead. The heap object header size is
obviously different between profiling and normal, however this works out
ok because we have to recompile for profiling anyway.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3094>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
