On 4/23/07, chromatic <[EMAIL PROTECTED]> wrote:
On Monday 23 April 2007 09:07, Jonathan Worthington wrote:
> chromatic wrote:
> > Jonathan, can you help us figure out why deleting these lines out of
> > init() fixes the problem? Are they vestigial?
> >
> > /* turn on marking of the class_data array */
> > PObj_data_is_PMC_array_SET(self);
>
> I saw those before and thought they were very suspect; I only gave SMOP
> a cursory glance for inspiration before digging into PDD15
> implementation though. When you set this flag, I believe the GC assumes
> the data pointer of the PMC points to a chunk of memory containing an
> array of pointers. It then looks at the int in the pmc_ext structure to
> say how many pointers there are. That way you don't have to write your
> own mark routine for some aggregate types. I may have the specific
> details wrong, but it's something like that.
Wow, that's actually how I guessed it would work - didn't want to
touch it without the okay from someone who knows GC, though. Plus, it
was really late it my timezone :)
I removed this dubious code in r18305 and applied Alek's original patch as
r18306.
Thanks, everyone!
Gracias. I attached one more small patch that gets rid of two
seemingly unnecessary lines in smop_init() - they're easy to miss when
one's looking at the big picture.
--
Alek Storm
Index: src/pmc/smop_attribute.pmc
===================================================================
--- src/pmc/smop_attribute.pmc (revision 18309)
+++ src/pmc/smop_attribute.pmc (working copy)
@@ -29,14 +29,11 @@
} SMOP_Attribute;
static void smop_init(Interp *interp, PMC *self) {
- SMOP_Attribute *smop = NULL;
-
/* turn on custom destruction since our PMC* array is dynamically allocated
*/
PObj_active_destroy_SET(self);
PMC_data(self) = mem_allocate_zeroed_typed(SMOP_Attribute);
- smop = SMOP_attr(self);
}
