[GHC] #9923: Offer copy-on-GC sliced arrays

[GHC]

#9923: Offer copy-on-GC sliced arrays
-------------------------------------+-------------------------------------
        Reporter:  dfeuer            |                   Owner:  simonmar
            Type:  feature request   |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Runtime System    |                 Version:  7.11
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by dfeuer):

 Replying to [comment:3 simonmar]:
 > The problem occurs if you have both a slice and a reference to the
 original array.  The GC can't know until the end of GC whether it should
 just copy the slice or keep the whole array, and neither can it copy both
 the slice and the array (GC would require more memory than the original
 heap).

 Why is that a problem, per se? The application I was thinking about when I
 came up with this idea was a function for converting an `Array` to a
 `Seq`. Currently, there are two ways to do this:

 1. You can lazily build a sequence "view" of the array. This is very fast,
 and only allocates subtrees of the finger tree as they are needed. But the
 entire underlying array is live until the last leaf of the tree is forced.

 2. You can build the sequence monadically, copying each element out of the
 array (using a nice little function from `Data.Primitive.Array`). This is
 sure to release the array, at the expense, of course, of actually building
 the whole sequence (a good bit larger than the array it represents) before
 using any of it.

 The copy-on-GC concept would, I believe, offer a middle ground between
 these options, with performance close to (1) with the leak safety of (2).

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