On 03/28/2015 08:54 PM, obastemur wrote:
Seems like the problem is GC'ed c++ side objects.
Let's say there is a persistent object on the c++ side(AddNamedRoot..)
JS::Heap<JS:Value> host; <- AddNamedRoot.. called on this
at some point, I do create an object
X_OBJECT = (JS_NewObject(.....))
host->setproperty->SOME_NAME = X_OBJECT
I do expect this X_OBJECT now has a reference on 'host' object so it shouldn't
be GC'ed. As it was with SM 340.
SM 370 GarbageCollects 'some part of' this X_OBJECT. If I call AddNamedRoot..
on X_OBJECT (which I shouldn't) everything is fine.
By host->setproperty->SOME_NAME = X_OBJECT, it sounds like you're
talking about your abstraction layer. Presumably, this gets translated
down to something like
RootedValue objval(cx, ObjectValue(*X_OBJECT));
JS_DefineProperty(cx, host, "some name", objval, 0);
I guess? That should definitely keep X_OBJECT alive as long as 'host' is
alive. And doing an AddNamedRoot on host means it's alive.
Though X_OBJECT's address might change during a GC -- are you tracing
whatever pointer you end up accessing X_OBJECT with? You have to trace
all pointers to GC objects. If you have multiple pointers to a GC thing
and trace only some of them, then the other pointers could be
invalidated by a moving GC (eg if it was initially allocated in the
nursery and then you had a minor GC move it to the tenured heap.)
(And I would guess that SM GCs all of X_OBJECT -- we don't collect parts
of objects -- but perhaps only part of whatever ends up using that space
gets overwritten.)
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
