b 2020 Pzt, 13:45
> tarihinde şunu yazdı:
> >
> > I’m not following this in detail, but do please make sure that the
> results of this discussion end up in a suitable Note. Obviously it’s not
> transparently clear as-is, and I can see clarity emerging
> >
> >
discussion end up in a suitable Note. Obviously it’s not
> > transparently clear as-is, and I can see clarity emerging
> >
> >
> >
> > Thanks!
> >
> >
> > Simon
> >
> >
> >
> > From: ghc-devs On Behalf Of Simon Marlow
> &g
t;
> Simon
>
>
>
> From: ghc-devs On Behalf Of Simon Marlow
> Sent: 24 February 2020 08:22
> To: Ömer Sinan Ağacan
> Cc: ghc-devs
> Subject: Re: Confused about PAP object layout
>
>
>
> On Thu, 20 Feb 2020 at 09:21, Ömer Sinan Ağacan wrote:
>
>
Sinan Ağacan
Cc: ghc-devs
Subject: Re: Confused about PAP object layout
On Thu, 20 Feb 2020 at 09:21, Ömer Sinan Ağacan
mailto:omeraga...@gmail.com>> wrote:
> I'm not sure what you mean by "garbage". The bitmap merely determines whether
> a field is a pointer,
I think the
On Thu, 20 Feb 2020 at 09:21, Ömer Sinan Ağacan
wrote:
> > I'm not sure what you mean by "garbage". The bitmap merely determines
> whether
> > a field is a pointer,
>
> I think the bitmap is for liveness, not for whether a field is pointer or
> not.
> Relevant code for building an info table for
Ömer Sinan Ağacan writes:
>> I'm not sure what you mean by "garbage". The bitmap merely determines whether
>> a field is a pointer,
>
> I think the bitmap is for liveness, not for whether a field is pointer or not.
> Relevant code for building an info table for a function:
>
> mk_pieces (Fun
> I'm not sure what you mean by "garbage". The bitmap merely determines whether
> a field is a pointer,
I think the bitmap is for liveness, not for whether a field is pointer or not.
Relevant code for building an info table for a function:
mk_pieces (Fun arity (ArgGen arg_bits)) srt_label
Ö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
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
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
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
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
>
13 matches
Mail list logo
