[PATCH] nci.pmc mark routine

[Steve Fink]

I'm confused by nci.pmc's mark() routine. It calls pobject_lives() on
the ->cache.struct_val pointer. But in set_string_keyed(), that seems
to be set to a pointer to a function, which is definitely not a PObj*.
The ->data field, on the other hand, appears to be a PObj*. And
changing mark() to mark it instead of struct_val makes the imcc tests
go from failing to passing on my machine. But I don't really know
what's going on here. Is the below patch correct?

Index: classes/nci.pmc
===================================================================
RCS file: /cvs/public/parrot/classes/nci.pmc,v
retrieving revision 1.9
diff -u -r1.9 nci.pmc
--- classes/nci.pmc 21 Jan 2003 23:15:04 -0000 1.9
+++ classes/nci.pmc 23 Jan 2003 04:07:04 -0000
@@ -28,9 +28,8 @@
}

void mark () {
- PMC *f = SELF->cache.struct_val;
- if (f)
- pobject_lives(INTERP, (PObj *)f);
+ if (SELF->data)
+ pobject_lives(INTERP, (PObj *)SELF->data);
}

STRING* name () {

[Leopold Toetsch]

Steve Fink wrote:

> I'm confused by nci.pmc's mark() routine. It calls pobject_lives() on
> the ->cache.struct_val pointer. But in set_string_keyed(), that seems
> to be set to a pointer to a function, which is definitely not a PObj*.

Yes, that's right.

> The ->data field, on the other hand, appears to be a PObj*.

No the data field is either the statically built native calling thunk
from nci.c:build_call_func() or a malloced thunk from JITs equivalent.

> ... Is the below patch correct?

Almost :-) No, we don't have a PMC to mark finally, the line
PObj_custom_mark_SET(SELF);
is wrong (and makes the mark obsolete)

Thanks for that analysis,

leo

[Leopold Toetsch]

Steve Fink wrote:

> I'm confused by nci.pmc's mark() routine.

Ok, nci's mark() is gone.

But - what confuses me - this patch needs a "make progclean" for changes
to take effect. Without default_mark gets called, because I don't know
where, something isn't recompiled.

Argh: pmc->vtable->init or ->set_string_keyed() is a totally static
thing. This implies, that after changing a vtable function, each file,
that is using a PMC of this type has to be rebuilt. Our dependencies
don't reflect this case.

leo