[webkit-dev] [JavaScriptCore] When to JSValueProtect?

[Alexei Sholik]

Hi Geoffrey,

> Therefore, if I'm not immediately returning the created object, it might
> get cleaned up prematurely.
>


> Because the GC scans the stack, and the value you just created is on the
> stack, it won’t be garbage collected right away.


What about the case when the creation of an object originates from C++
land? For example, if I tap on a view and it needs to invoke a JS callback.
I'm creating an object to pass to JSEvaluateScript or as an argument to
JSObjectCallAsFunction.

At this point, the code is not inside the JS stack, so is it possible for
an object to be collected between the calls to JSObjectMake and
JSObjectCallAsFunction?

Thanks!


On Sat, Dec 7, 2013 at 8:55 PM, Geoffrey Garen <ggaren at apple.com> wrote:

> > My question in short: is it necessary to call JSValueProtect right after
> object/value creation in C++?
>
> No.
>
> > I don't know the semantics of the GC, but I'm assuming that almost any
> call to a JSC function that takes a context may run a garbage collection
> cycle.
>
> Yes.
>
> > Therefore, if I'm not immediately returning the created object, it might
> get cleaned up prematurely.
>
> Because the GC scans the stack, and the value you just created is on the
> stack, it won’t be garbage collected right away.
>
> > Could you share some advice on the proper usage of JSValueProtect and on
> keeping objects from going away unexpectedly?
>
> If you store a JSValueRef or JSObjectRef into a C/C++ heap object, then
> you should JSValueProtect the JSValueRef/JSObjectRef, since your reference
> to it will outlast the pointer to it on the stack.
>
> Use JSValueProtect/JSValueUnprotect just like you would use any other
> reference-counting API — such as CFRetain/CFRelease, NSObject
> retain/release, or IUnknown AddRef/RemoveRef — with the added feature that
> you do not need to retain local variables.
>
> Geoff




-- 
Best regards
Alexei Sholik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20131207/4449225e/attachment.html>