Commits on Source (13)
-
In pursuit of: #22736. This MR moves ad-hoc symbols used throughout the js backend into a single symbols file. Why? First, this cleans up the code by removing ad-hoc strings created on the fly and therefore makes the code more maintainable. Second, it makes it much easier to eventually type these identifiers.
6bd850e8 -
This patch replaces the ad-hoc `MYTASK_USE_TLV` with the `CC_SUPPORTS_TLS` macro. If TLS support is detected by autoconf, then we should use that for managing `myTask` in the threaded RTS.
f3017dd3 -
Duncan Coutts authored
In the GC, evacuate() is prepared to deal with some heap objects that are not in the HEAP_ALLOCED() memory space. These are mainly the heap objects that GHC puts into the data sections of object files. It is also useful however to allow ByteArray# and MutableByteArray# heap objects to appear outside of the HEAP_ALLOCED() memory space. These have the ARR_WORDS closure type and contain no pointer should be easy to deal with. Indeed evacuate() already deals with closure types for constructors containing no pointers by doing nothing. So we just tack the ARR_WORDS case into this group of closure types that are permitted outside the HEAP_ALLOCED area but otherwise ignored.
43e7531b -
Duncan Coutts authored
It places a byte array heap object header at the given address, which must be outside the heap. It also sets the byte array size.
438dc732 -
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.
4d4bddb4 -
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.
be9e4975 -
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.
71b840b4 -
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#.
7b06912a -
Duncan Coutts authoredf810809f
-
Duncan Coutts authored
And refer to it from the various places involved in the scheme.
7cdfb04e -
Duncan Coutts authored2eef181f
-
davide authored45dcfc64
-
Reinier Maas authored70d3f785
Showing
- compiler/GHC/Builtin/primops.txt.pp 78 additions, 0 deletionscompiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/JS/Ident.hs 12 additions, 8 deletionscompiler/GHC/JS/Ident.hs
- compiler/GHC/JS/JStg/Monad.hs 1 addition, 1 deletioncompiler/GHC/JS/JStg/Monad.hs
- compiler/GHC/JS/JStg/Syntax.hs 13 additions, 5 deletionscompiler/GHC/JS/JStg/Syntax.hs
- compiler/GHC/JS/Make.hs 14 additions, 18 deletionscompiler/GHC/JS/Make.hs
- compiler/GHC/JS/Syntax.hs 1 addition, 1 deletioncompiler/GHC/JS/Syntax.hs
- compiler/GHC/StgToCmm/Prim.hs 1 addition, 0 deletionscompiler/GHC/StgToCmm/Prim.hs
- compiler/GHC/StgToJS.hs 17 additions, 0 deletionscompiler/GHC/StgToJS.hs
- compiler/GHC/StgToJS/Apply.hs 93 additions, 91 deletionscompiler/GHC/StgToJS/Apply.hs
- compiler/GHC/StgToJS/Arg.hs 2 additions, 2 deletionscompiler/GHC/StgToJS/Arg.hs
- compiler/GHC/StgToJS/Closure.hs 2 additions, 2 deletionscompiler/GHC/StgToJS/Closure.hs
- compiler/GHC/StgToJS/Expr.hs 16 additions, 15 deletionscompiler/GHC/StgToJS/Expr.hs
- compiler/GHC/StgToJS/FFI.hs 25 additions, 25 deletionscompiler/GHC/StgToJS/FFI.hs
- compiler/GHC/StgToJS/Heap.hs 1 addition, 1 deletioncompiler/GHC/StgToJS/Heap.hs
- compiler/GHC/StgToJS/Ids.hs 6 additions, 7 deletionscompiler/GHC/StgToJS/Ids.hs
- compiler/GHC/StgToJS/Linker/Linker.hs 19 additions, 19 deletionscompiler/GHC/StgToJS/Linker/Linker.hs
- compiler/GHC/StgToJS/Literal.hs 4 additions, 4 deletionscompiler/GHC/StgToJS/Literal.hs
- compiler/GHC/StgToJS/Object.hs 1 addition, 1 deletioncompiler/GHC/StgToJS/Object.hs
- compiler/GHC/StgToJS/Prim.hs 212 additions, 207 deletionscompiler/GHC/StgToJS/Prim.hs
- compiler/GHC/StgToJS/Profiling.hs 45 additions, 17 deletionscompiler/GHC/StgToJS/Profiling.hs
This diff is collapsed.