Re: Object unloading confusion
Hi Omer
The point of the heap scan is to find *info pointers* into objects that we
want to unload, since we can't unload those.
What about static object pointers? Well, those would be found by traversing
the static_objects list, which we also do in checkUnload. Except that
static_objects doesn't contain all the static objects - that's one of the
problems identified by this ticket.
Primitive objects can't have an info pointer into a dynamically loaded
object, because all their info pointers point into the RTS.
Hope that helps!
Simon
On Wed, 15 Apr 2020 at 13:06, Ömer Sinan Ağacan
wrote:
> To answer my own question
>
> > So if I see a constructor with a reference to an object code in its
> payload
> > I'll not mark the object code.
>
> We don't visit payload as objects pointed from the payload will be visited
> during the scan later (or they're already visited if they come before the
> constructor in a block).
>
> The 'prim' variable in that code is still a little bit confusing. For
> example we
> never check an MVAR for whether it's an unloadable object or not:
>
> case MVAR_CLEAN:
> case MVAR_DIRTY:
> prim = true;
> size = sizeW_fromITBL(info);
> break;
>
> ...
>
> if (!prim) {
> checkAddress(addrs,info, s_indices);
> }
>
> Would be good to know why it's fine to not check MVARs and other kinds of
> objects that we skip in that code.
>
> Ömer
>
> Ömer Sinan Ağacan , 15 Nis 2020 Çar, 12:35
> tarihinde şunu yazdı:
> >
> > Hi Simon,
> >
> > I'm looking at object unloading code in CheckUnload.c. My understanding
> of how
> > unloading works is:
> >
> > - When unloading of an object is requested the object is added to
> > `unloaded_objects`.
> > - When `unloaded_objects` is not empty, after GC, we scan the heap for
> any
> > references to objects. This is done in `searchHeapBlocks` called by
> > `checkUnload`.
> > - When `searchHeapBlocks` finds a reference to an object code it marks
> the
> > object code.
> > - After scanning the heap any objects in `unloaded_objects` that are not
> marked
> > are unloaded.
> >
> > Does this sound right so far?
> >
> > What I'm confused about is `searchHeapBlocks`. As far as I can see it
> just skips
> > all objects other than stacks. For example here's the code for scanning a
> > constructor:
> >
> > case CONSTR:
> > case CONSTR_NOCAF:
> > case CONSTR_1_0:
> > case CONSTR_0_1:
> > case CONSTR_1_1:
> > case CONSTR_0_2:
> > case CONSTR_2_0:
> > size = sizeW_fromITBL(info);
> > break;
> >
> > So if I see a constructor with a reference to an object code in its
> payload I'll
> > not mark the object code. This looks wrong to me. I don't understand why
> we only
> > care about stacks and nothing else. Could you comment on this?
> >
> > Thanks,
> >
> > Ömer
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Object unloading confusion
To answer my own question
> So if I see a constructor with a reference to an object code in its payload
> I'll not mark the object code.
We don't visit payload as objects pointed from the payload will be visited
during the scan later (or they're already visited if they come before the
constructor in a block).
The 'prim' variable in that code is still a little bit confusing. For example we
never check an MVAR for whether it's an unloadable object or not:
case MVAR_CLEAN:
case MVAR_DIRTY:
prim = true;
size = sizeW_fromITBL(info);
break;
...
if (!prim) {
checkAddress(addrs,info, s_indices);
}
Would be good to know why it's fine to not check MVARs and other kinds of
objects that we skip in that code.
Ömer
Ömer Sinan Ağacan , 15 Nis 2020 Çar, 12:35
tarihinde şunu yazdı:
>
> Hi Simon,
>
> I'm looking at object unloading code in CheckUnload.c. My understanding of how
> unloading works is:
>
> - When unloading of an object is requested the object is added to
> `unloaded_objects`.
> - When `unloaded_objects` is not empty, after GC, we scan the heap for any
> references to objects. This is done in `searchHeapBlocks` called by
> `checkUnload`.
> - When `searchHeapBlocks` finds a reference to an object code it marks the
> object code.
> - After scanning the heap any objects in `unloaded_objects` that are not
> marked
> are unloaded.
>
> Does this sound right so far?
>
> What I'm confused about is `searchHeapBlocks`. As far as I can see it just
> skips
> all objects other than stacks. For example here's the code for scanning a
> constructor:
>
> case CONSTR:
> case CONSTR_NOCAF:
> case CONSTR_1_0:
> case CONSTR_0_1:
> case CONSTR_1_1:
> case CONSTR_0_2:
> case CONSTR_2_0:
> size = sizeW_fromITBL(info);
> break;
>
> So if I see a constructor with a reference to an object code in its payload
> I'll
> not mark the object code. This looks wrong to me. I don't understand why we
> only
> care about stacks and nothing else. Could you comment on this?
>
> Thanks,
>
> Ömer
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Object unloading confusion
Hi Simon, I'm looking at object unloading code in CheckUnload.c. My understanding of how unloading works is: - When unloading of an object is requested the object is added to `unloaded_objects`. - When `unloaded_objects` is not empty, after GC, we scan the heap for any references to objects. This is done in `searchHeapBlocks` called by `checkUnload`. - When `searchHeapBlocks` finds a reference to an object code it marks the object code. - After scanning the heap any objects in `unloaded_objects` that are not marked are unloaded. Does this sound right so far? What I'm confused about is `searchHeapBlocks`. As far as I can see it just skips all objects other than stacks. For example here's the code for scanning a constructor: case CONSTR: case CONSTR_NOCAF: case CONSTR_1_0: case CONSTR_0_1: case CONSTR_1_1: case CONSTR_0_2: case CONSTR_2_0: size = sizeW_fromITBL(info); break; So if I see a constructor with a reference to an object code in its payload I'll not mark the object code. This looks wrong to me. I don't understand why we only care about stacks and nothing else. Could you comment on this? Thanks, Ömer ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
