Allow the user to pick the address that the RTS reserves for the heap

We stumbled upon a case where an external library (OpenCL) does not work if a specific address (0x200000000) is taken.

It so happens that osReserveHeapMemory starts trying to mmap at 0x200000000:

        void *hint = (void*)((W_)8 * (1 << 30) + attempt * BLOCK_SIZE);
        at = osTryReserveHeapMemory(*len, hint);

This makes it impossible to use Haskell programs compiled with GHC 8 with C functions that use OpenCL.

See this example https://github.com/chpatrick/oclwtf for a repro.

My proposal is to allow the user to work around this kind of behavior outside our control by letting the user override the starting address through an RTS command line flag.

Trac metadata

Trac field	Value
Version	8.0.1
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Runtime System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	simonmar
Operating system
Architecture

changed weight to 5

added RTS Tfeature request Trac import labels

changed milestone to %8.0.2

A similar issue came up with Accelerate.

@bitonic my current (partially working) solution is to use an __attribute__((constructor)) function to mmap the region that CUDA/OpenCL requires before the RTS initialises. The RTS will then avoid it and you can munmap it right before initialising CUDA/OpenCL:

https://github.com/tmcdonell/cuda/blob/hotfix/ghc-8/cbits/init.c

You can also initialise OpenCL directly in the constructor function, but then you'll spin up the GPU many times during compilation/haddock (every time a package loads your library). (This is simpler and what the master branch of the above repo does, actually.)

Both those approaches work for compiled programs, but not in ghci, and I haven't had a chance to dig to the bottom of it yet.

Trac metadata

Trac field	Value
CC	chak, simonmar, trevor.mcdonell@gmail.com → chak, simonmar, tmcdonell

@tmcdonell , that's clever, I did not know about __attribute__((constructor)). It's a nice workaround until we get the RTS workaround.

closed

Hadn't noticed that the ticket wasn't set on the phabricator diff correctly before I committed.

In any case, committed as 1b5f9207

Thanks for the report and fix bitonic!

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

reopened

added 1 deleted label

closed

Merged to ghc-8.0 as 658f0354.

removed 1 deleted label

added Pnormal label