Commits on Source (8)
-
Duncan Coutts authored
Allow rts/sm/HeapAlloc.h to be #included by CMM code and have it provide a suitable implementation of HEAP_ALLOCED. The HEAP_ALLOCED system has three implementations, the large address space case, two fallbakc impls, one for 32bit and one for 64bit. The first two are simple enough that we can provide a HEAP_ALLOCED macro that can be used in a CMM expression context. The 64bit fallback case is rather more tricky. We provide a different interface to HEAP_ALLOCED for this case, which has to be called in a statement/"callish" style.
82ee2a9d -
Duncan Coutts authored
The isByteArrayPinned# primop works by looking up the block descriptor for the byte array to see if it lives in a pinned area or not. This of course cannot work for byte arrays that are not HEAP_ALLOCATED since they don't have block descriptors. The solution is to check if it is HEAP_ALLOCATED first. Since this is done in CMM code we make use of the new HEAP_ALLOCATED support for CMM. It is a bit awkward since it does not have a uniform interface.
06c11e51 -
Duncan Coutts authored
Closes issue #17747 Test that we can allocate ByteArray#s outside of the HEAP_ALLOCED() address space without upsetting the GC. To be extra sure we attach weak pointers with C finalizers to the ByteArray#s. We keep them alive and run a major GC so that the GC has to trace the live ByteArray#s. Prior to the first patch in this series, doing this would upset the GC because the GC does not expect heap objects with closure type ARR_WORDS to exist outside the GC heap. > internal error: evacuate(static): strange closure type 42 Finally we allow everything to be GC'd again, and check that the C finalizers did run. This feature also required a change to the isByteArrayPinned# which itself required a CMM implementation of the HEAP_ALLOCED system. So we also add a check that the CMM and C implementations of HEAP_ALLOCED agree with each other.
6f9e3070 -
Duncan Coutts authored
Add a sub-subsection in the chapter on GHC extensions to the FFI, under the existing Memory Allocation subsection. Explain that it's permitted to have {Mutable}ByteArray# outside the heap and the tricky associated constraints. Mention the new primop placeByteArray#.
9669bfd3 -
Duncan Coutts authored2d4a2b3a
-
Duncan Coutts authored
And refer to it from the various places involved in the scheme.
0c5fee65 -
Duncan Coutts authored334262be
-
davide authoredb26782c8
Showing
- compiler/GHC/Builtin/primops.txt.pp 73 additions, 2 deletionscompiler/GHC/Builtin/primops.txt.pp
- docs/users_guide/exts/ffi.rst 31 additions, 0 deletionsdocs/users_guide/exts/ffi.rst
- rts/Inlines.c 1 addition, 0 deletionsrts/Inlines.c
- rts/PrimOps.cmm 25 additions, 10 deletionsrts/PrimOps.cmm
- rts/include/rts/storage/HeapAlloc.h 56 additions, 2 deletionsrts/include/rts/storage/HeapAlloc.h
- rts/sm/Evac.c 1 addition, 0 deletionsrts/sm/Evac.c
- testsuite/tests/rts/Makefile 6 additions, 0 deletionstestsuite/tests/rts/Makefile
- testsuite/tests/rts/T17747.hs 184 additions, 0 deletionstestsuite/tests/rts/T17747.hs
- testsuite/tests/rts/T17747.stdout 8 additions, 0 deletionstestsuite/tests/rts/T17747.stdout
- testsuite/tests/rts/T17747_c.c 28 additions, 0 deletionstestsuite/tests/rts/T17747_c.c
- testsuite/tests/rts/T17747_cmm.cmm 18 additions, 0 deletionstestsuite/tests/rts/T17747_cmm.cmm
- testsuite/tests/rts/all.T 7 additions, 0 deletionstestsuite/tests/rts/all.T
testsuite/tests/rts/T17747.hs
0 → 100644
testsuite/tests/rts/T17747.stdout
0 → 100644
testsuite/tests/rts/T17747_c.c
0 → 100644
testsuite/tests/rts/T17747_cmm.cmm
0 → 100644