Ah, too bad about reuse. What do you mean about walking over both pointers and non-pointers? The extra word (for pointers-first layout) or few words (for bitmapped) will be more than made up for in most cases by not needing extra heap objects between a node and its children.
Simon has explained that these unsafe coercions between lifted and unlifted are really *too* unsafe (so we'd probably have to NOINLINE like mad). Once we have BoxedRep, we can fix that part by offering unsafe primops that allow lifted things to be read from/written to arrays of unlifted things and vice versa, but I'm not sure that's so useful if we can't get a little bit of unboxed (non-pointer) stuff in there too. On Thu, Oct 8, 2020, 8:32 AM Ben Gamari <b...@smart-cactus.org> wrote: > On October 7, 2020 2:02:53 PM EDT, David Feuer <david.fe...@gmail.com> > wrote: > >Yes, the bitmap structures used to encode the structure of stack > >frames. These *look* like they might be reusable for mix-and-match > >arrays in Haskell-land. If so, that could be a pretty cheap new > >feature. > > Ahh, yes. In principle we could expose a new array type allowing the user > to specify the pointer-ness of each entry. This wouldn't reuse any of the > large bitmap machinery since these must be specified in the info table > rather than the closure but the idea is similar. Implementation would > require a new set of primops along with GC support but I suspect that none > of this is too hard. > > All these being said, this may not be terribly efficient for garbage > collection since the GC will need to walk over both pointers and > non-pointers, trashing a good amount of cache in the process. Moreover, the > array itself would be larger, due to the two bitmaps. > > I suspect most applications would be on the whole better served by a > structure of arrays approach to achieve the same idea. If you have > multiple pointers and locality is a concern then you can even pack all of > your pointers into a single array with some indexing magic and an > unsafeCoerce. > > Cheers, > > - Ben >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
