I think that makes sense, with the invariant that n_args <= bitmap_size. We
evacuate the arguments used by the function but not others. Thanks.
It's somewhat weird to see an object with useful stuff, then garbage, then
useful stuff again in the heap, but that's not an issue by itself. For example
if I have something like
[pap_info, x, y, z]
and according to the function `y` is dead, then after evacuating I get
[pap_info, x, <garbage>, z]
This "garbage" is evacuated again and again every time we evacuate this PAP.
Ömer
Alexis King <lexi.lam...@gmail.com>, 14 Şub 2020 Cum, 18:43 tarihinde
şunu yazdı:
>
> Disclaimer: I am not an expert. But I happened to have been looking at this
> code just yesterday, so I’ll try to answer to check my understanding. :)
>
> Fundamentally, a PAP is not fully-saturated, so the number of arguments in
> its payload may be smaller than the information contained in the function’s
> bitmap. scavenge_large_bitmap calls walk_large_bitmap, which uses the bitmap
> as a “ruler” to guide the traversal, lining up each element in the payload to
> information in the bitmap. But the traversal only actually walks a payload of
> the specified size, so if there’s less information in the payload than there
> is information in the bitmap, the traversal will just terminate early.
>
> > On Feb 14, 2020, at 09:30, Ömer Sinan Ağacan <omeraga...@gmail.com> wrote:
> >
> > Right, I think that's the problem. We then pass the same "size" to
> > scavenge_large_bitmap as the size of the bitmap. So we assume size of the
> > bitmap
> > is pap->n_args.
> >
> > So the call stack is
> >
> > - scavenge_PAP, calls scavenge_PAP_payload with pap->n_args as "size"
> > - scavenge_PAP_payload, calls scavenge_large_bitmap with "size" (==
> > pap->n_args)
> > as the bitmap's size
> >
> > Is this expected?
> >
> > Ömer
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
