[GHC] #13944: Introduce synchronized FFI

[GHC]

#13944: Introduce synchronized FFI
-------------------------------------+-------------------------------------
        Reporter:  winter            |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by winter:

@@ -20,0 +20,4 @@
+ 4. When the FFI finish, if we're GC ing, put current capaity into sleep(if
+ we can find a way to let it join parallel GC that would be better).
+ Otherwise it continue to work.
+
@@ -23,1 +27,2 @@
- anyway.
+ anyway, we can combine this with the new `-qn` RTS parameter: as long as
+ there're more than `n` threads can join GC, we do GC.

New description:

 During hacking on ghc I/O libraries, i find an
 [https://github.com/winterland1989/stdio/tree/master/bench/diskIO
 interesting situation], to summarize: There're some FFI calls that vary a
 lot in time duration, this makes unsafe FFI bad because it make GC hard to
 synchronize all capacities. OTOH safe FFI 's overhead is too large to
 justify its usage.

 After some thought i think we should introduce a new FFI type, let call it
 `synchronized` for now, it should:

 1. Have the same requirement as safe FFI of what kind of argument we can
 pass, e.g. pinned ByteArray, pass by value primitive type, etc.

 2. It works like unsafe FFI call by directly jump to c code using current
 capacity's stack.

 3. It should mark current capacity GC ready, and doesn't participate next
 GC.

 4. When the FFI finish, if we're GC ing, put current capaity into sleep(if
 we can find a way to let it join parallel GC that would be better).
 Otherwise it continue to work.

 The point is that if a FFI call doesn't need GC guarantee, then it
 shouldn't stop GC running. The next GC will not be running with all
 threads, but that's not too terrible since it doesn't scale too much
 anyway, we can combine this with the new `-qn` RTS parameter: as long as
 there're more than `n` threads can join GC, we do GC.

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13944#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler