Ticket #178 (closed todo: fixed)

Opened 6 years ago

Last modified 6 years ago

[TODO] remove PMC_struct_val from src/gc/mark_sweep.c

Reported by: cotto Owned by: whiteknight
Priority: normal Milestone: 0.9.1
Component: core Version:
Severity: medium Keywords: gc pmc
Cc: Language:
Patch status: Platform: all

Description (last modified by cotto) (diff)

src/gc/mark_sweep.c has two (apparently complementary) uses of PMC_struct_val. Since the PMC UnionVal is being deprecated, the information stored there needs to be moved elsewhere.

This task is distinct from the rest of the PMC UnionVal deprecation because mark_sweep.c uses the union for PMC-agnostic information. For that reason, these instances of PMC_struct_val can't be replaced with PMC-specific GETATTR/SETATTR macros, requiring another solution.

Change History

Changed 6 years ago by cotto

  • type changed from bug to todo
  • description modified (diff)
  • summary changed from uses of PMC_struct_val in src/gc/mark_sweep.c to [TODO] remove PMC_struct_val from src/gc/mark_sweep.c

Changed 6 years ago by whiteknight

  • status changed from new to assigned
  • component changed from none to core
  • owner set to whiteknight
  • platform set to all
  • milestone set to 0.9.1
  • keywords gc pmc added

Changed 6 years ago by whiteknight

The GC works on PObjs, and objects that are isomorphic with PObjs (PMCs and STRINGs, mostly). The definition of PObj is this:

typedef struct pobj_t {
    UnionVal u;
    Parrot_UInt flags;
} pobj_t;

If the UnionVal disappears (which I assume is the end goal), then we don't have any good place in the PObj to store a pointer like this. The pointer in question joins PObjs together into a linked list.

GC_MS also uses PObj_buflen(p), which is also part of the UnionVal structure. We could easily repurpose ->flags to take the place of PObj_buflen(p) here, but then we have no place to store the next-on-the-free-list pointer that's being displaced here.

If we add a new generic void* "->ptr" field to Pobjs in place of the UnionVal, this could serve the purpose nicely. Also, it would help us transition the GC more gracefully to one that uses headers (such as a copying collector, or a real generational one).

Even a small change like this is going to require a lot of regression testing since the GC is so temperamental. I would love to hear what other people think about this first though.

Changed 6 years ago by whiteknight

  • status changed from assigned to closed
  • resolution set to fixed

Resolved in r36390.

Note: See TracTickets for help on using tickets.