On Fri, 14 Feb 2020 at 11:49, Ömer Sinan Ağacan
wrote:
> Hi Simon,
>
> In this code: (slightly simplified)
>
> StgPtr
> scavenge_PAP (StgPAP *pap)
> {
> evacuate(>fun);
> return scavenge_PAP_payload (pap->fun, pap->payload, pap->n_args);
> }
>
> StgPtr
>
Hi Simon,
In this code: (slightly simplified)
StgPtr
scavenge_PAP (StgPAP *pap)
{
evacuate(>fun);
return scavenge_PAP_payload (pap->fun, pap->payload, pap->n_args);
}
StgPtr
scavenge_PAP_payload (StgClosure *fun, StgClosure **payload, StgWord size)
{
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
Compl Yue via ghc-devs writes:
> I verified that the problem in GHC 8.6.5 can be solved by backporting
> merge request 87, a patch as well as the build steps have been updated
> at https://gitlab.haskell.org/complyue/smart-ghc8, enjoy!
>
Great work figuring out the issue! Thanks for your work
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
Ömer Sinan Ağacan writes:
> 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
Ömer Sinan Ağacan writes:
> 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
Hi all,
I’m trying to understand how to properly call an unknown function from
low-level Cmm code. If I’m just applying a function to a state token, it’s
easy; I can just do
R1 = io;
jump stg_ap_v_fast [R1];
since the calling convention is consistent in that case. But what if my
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
