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 <omeraga...@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs