On Fri, 14 Feb 2020 at 11:49, Ömer Sinan Ağacan <omeraga...@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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs