Cabal flag for linking with jemalloc ?

[ulidtko]

Hi again @phadej 👋

Asking for opinion before a PR.

In followup to haskellari/postgresql-simple#114 — I've found a heavy heap fragmentation issue in my LO-intense workload — and determined that it's not the Haskell heap which got fragmented, but rather the C malloc one.

postgresql-libpq/src/Database/PostgreSQL/LibPQ.hs

Lines 2012 to 2025 in 900abcb

	loRead :: Connection -> LoFd -> Int -> IO (Maybe B.ByteString)
	loRead connection (LoFd !fd) !maxlen
	= withConn connection $ \c -> do
	buf <- mallocBytes maxlen
	len_ <- c_lo_read c fd buf (fromIntegral maxlen)
	let len = fromIntegral len_
	if len < 0
	then do
	free buf
	return Nothing
	else do
	bufre <- reallocBytes buf len
	buffp <- newForeignPtr finalizerFree bufre
	return $! Just $! B.fromForeignPtr buffp 0 len

☝️ Here, the reallocBytes call, while releasing the extra unused space under maxLen — will create differing-length allocations, which depend on LO sizes. So if I do tens of thousands of varying-size LO reads — this puts stress onto malloc to handle fragmentation well.

The fixed graph on the left — is exact same test running against exact same Haskell executable, but with LD_PRELOAD=jemalloc.so. The baseline on the right — with stock allocator in libc6 2.35-0ubuntu3.1 on Ubuntu 22.04.2 LTS.

Would you approve adding a flag jemalloc to the cabal-file here?

https://jemalloc.net/ to perhaps save you a search query 😅

[phadej]

Would you approve adding a flag jemalloc to the cabal-file here?

No. mallocBytes comes from base, and I don't have to worry about how it works & whether different allocators would conflict.

[ulidtko]

No. mallocBytes comes from base, and I don't have to worry about how it works & whether different allocators would conflict.

Okay, got it 👍 Fair enough, good to know, thanks for reply 🙏

I'm closing the issue then.

Had just one question — whether the LO buffers could be allocated on Haskell heap instead of C heap?
But will self-answer.

There's this mallocForeignPtrBytes API — it's fairly old, base-4.0.0.0 has it — conceptually equivalent to mallocBytes _ >>= newForeignPtr finalizerFree, but backed by newPinnedByteArray# instead.

Superficially it seems usable here — but it's not straightforward, due to unknown-beforehand allocation length which the reallocBytes call handles. So, without a realloc variation for bytearray-ForeignPtr's (which I don't see¹), we'll either "slop-leak" unused trailing memory, or will need buffer copying.

---

¹ shrinkMutableByteArray# exists, but isn't threaded through to ForeignPtr API.