Confused about PAP object layout

Simon Marlow marlowsd at gmail.com
Fri Feb 14 15:08:02 UTC 2020


On Fri, 14 Feb 2020 at 11:49, Ömer Sinan Ağacan <omeragacan at gmail.com>
wrote:

> Hi Simon,
>
> In this code: (slightly simplified)
>
>     StgPtr
>     scavenge_PAP (StgPAP *pap)
>     {
>         evacuate(&pap->fun);
>         return scavenge_PAP_payload (pap->fun, pap->payload, pap->n_args);
>     }
>
>     StgPtr
>     scavenge_PAP_payload (StgClosure *fun, StgClosure **payload, StgWord
> size)
>     {
>         const StgFunInfoTable *fun_info =
> get_fun_itbl(UNTAG_CONST_CLOSURE(fun));
>         StgPtr p = (StgPtr)payload;
>
>         switch (fun_info->f.fun_type) {
>         case ARG_GEN_BIG:
>             scavenge_large_bitmap(p, GET_FUN_LARGE_BITMAP(fun_info), size);
>             p += size;
>             break;
>         ...
>         }
>         return p;
>     }
>
> Here the `size` argument in `scavenge_PAP_payload` is the number of
> arguments
> applied to the function in `pap->fun`. But when scavenging the function's
> bitmap
> we're using this number as the size of the bitmap which doesn't make sense
> to
> me, because I think size of the function's bitmap and size of the PAP's
> payload
> may be different.
>

"size" is an argument to scavenge_PAP_payload(), and when we call it we
pass pap->n_args as the value, not the bitmap's size.

Does that help?

Cheers
Simon



>
> Or in other words I may have the same function used in many PAPs with
> different
> n_args, but that'd be buggy if this code is correct.
>
> I haven't checked every single place where we build a PAP but for example
> the
> `NEW_PAP` macro uses the argument's (another PAP) function directly,
> without
> making any bitmap-related changes, but bumps n_args by one. If the code
> above is
> right, then this new PAP will be scavenged incorrectly.
>
> Am I missing anything?
>
> Thanks,
>
> Ömer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200214/68f97358/attachment.html>


More information about the ghc-devs mailing list