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.
On Wed, Oct 7, 2020 at 1:37 PM Ben Gamari <b...@smart-cactus.org> wrote: > > David Feuer <david.fe...@gmail.com> writes: > > > It appears that the RTS has more flexibility in its array representations > > than users can access through primops. In particular, there are > > "pointers-first" and "bitmapped" arrays. Are these used for the evaluation > > stack or something? I'd be very interested in getting user access to some > > of this power. > > > I'm a bit unclear on what in particular you are referring to. GHC supports > four types of arrays: > > * ByteArray#: Just a pile of bytes > > * Array#: An array of pointers to lifted things with a card table used > to record which regions of the array are "dirty" (and therefore may > need to be scavenged for young-generation references. > > * ArrayArray#: An array of pointers to Array#s. These also have a card > table. This really should be > generalized and called UnliftedArray#, but oh well. > > * SmallArray#: An array of pointers to lifted things without a card > table. The lack of card table means that the entire array must be > scavenged if any part of it has changed. > > We don't support arrays that mix pointers and non-pointers. > > Perhaps you are thinking of the bitmap structures used to encode the > structure of stack frames? > > Cheers, > > - Ben _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs