Object unloading confusion

[Ömer Sinan Ağacan]

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 <omeragacan at gmail.com>, 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