Re: How do I trace objects on the heap with JS 59

On Tue, Aug 14, 2018 at 2:19 PM, Boris Zbarsky <[email protected]> wrote:

>
> Given that, deleting the FrontEnd in the object's finalizer doesn't really
> make sense: the FrontEnd will keep the object alive as long as the FrontEnd
> is alive, as far as I can tell.
>
> What is the desired lifetime relationship here between the FrontEnd, the
> BackEnd, and the JSObject that the FrontEnd points to?
>
>
Ah, thank you for catching that! Ok, so the JSObject has a C++ Object that
it mirrors, as a high-level interface. The desired relationship is that C++
or JS can work on their respective counterpart and have changes reflected
accordingly. (FrontEnd and BackEnd are simply wrappers that contain
pointers to them.)

The problem is when the JS Object goes out of scope, it never really goes
out of scope! They all get GC'd at Context Destruction. These JSObjects are
created in my JS API with `new`, so in C++ that would be normal to keep
them alive until `delete`, but in JS, we don't want this!

I can't think of any elegant solutions off the top of my head. I don't
think storing raw JSObject* pointers in the C++ is viable. Neither is
reworking away the C++ mirror entirely. It would be great if there was a
distinction between Heap/Rooted objects that I could test for during some
GC trace/hook, but there's not a better place to delete the Heap<JSObject*>
wrapper, is there? Is there a way I can check for when a JSObject
"would've" gone out of scope? (such as: upon RootedObject normally going
out of scope)

If anybody knows of a better/common methodology, I would gladly take some
advice. I don't want to impose otherwise, I'm sure I can figure something
out. (Seems like, at least in my program, I can do some kind of a check in
a GC trace somewhere, to see if the JSObject was actually used by my API.)

Again, I really appreciate the replies, everyone! Thanks for catching that,
Boris.
Thanks,
James