Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Alternative for the Deprecated JS_EnterLocalRootScope()
33 views
Skip to first unread message
Masquerade
May 7, 2012, 11:13:46 AM5/7/12
to
The JSAPI online documentation for JS_EnterLocalRootScope() says it is
deprecated. So what should we do to ensure our JSObject/JSString is
rooted? e.g.
JSString * mystring=JS_NewStringCopyZ(cx, "a string") ;
JS_GC(cx);
//mystring still here?
What should be the proper way to ensure a JSString created locally is
not garbage collected if JS_EnterLocalRootScope() is deprecated?
deprecated. So what should we do to ensure our JSObject/JSString is
rooted? e.g.
JSString * mystring=JS_NewStringCopyZ(cx, "a string") ;
JS_GC(cx);
//mystring still here?
What should be the proper way to ensure a JSString created locally is
not garbage collected if JS_EnterLocalRootScope() is deprecated?
Boris Zbarsky
May 7, 2012, 11:24:12 AM5/7/12
to
On 5/7/12 11:13 AM, Masquerade wrote:
> The JSAPI online documentation for JS_EnterLocalRootScope() says it is
> deprecated. So what should we do to ensure our JSObject/JSString is
> rooted? e.g.
>
> JSString * mystring=JS_NewStringCopyZ(cx, "a string") ;
> JS_GC(cx);
> //mystring still here?
At the moment, the stack scanner should keep mystring live in this
> The JSAPI online documentation for JS_EnterLocalRootScope() says it is
> deprecated. So what should we do to ensure our JSObject/JSString is
> rooted? e.g.
>
> JSString * mystring=JS_NewStringCopyZ(cx, "a string") ;
> JS_GC(cx);
> //mystring still here?
situation, if you actually use the pointer after the JS_GC call.
What things will look like after the moving GC work, I'm not sure.
-Boris
Masquerade
May 7, 2012, 12:07:24 PM5/7/12
to
mystring to a static var
e.g.
static JSString * staticstr;
JSString * mystring=JS_NewStringCopyZ(cx, "a string") ;
staticstr=mystring;
mystring=NULL;
JS_GC(cx);
Boris Zbarsky
May 7, 2012, 1:03:37 PM5/7/12
to
On 5/7/12 12:07 PM, Masquerade wrote:
> You mean so long as mystring is a local variable? What if I assign
> mystring to a static var
> e.g.
>
> static JSString * staticstr;
> JSString * mystring=JS_NewStringCopyZ(cx, "a string") ;
> staticstr=mystring;
> mystring=NULL;
> JS_GC(cx);
I believe you need to root it then. But note that a local root scope
> You mean so long as mystring is a local variable? What if I assign
> mystring to a static var
> e.g.
>
> static JSString * staticstr;
> JSString * mystring=JS_NewStringCopyZ(cx, "a string") ;
> staticstr=mystring;
> mystring=NULL;
> JS_GC(cx);
wouldn't have helped in that situation anyway. That's why it's
deprecated: everything it did, pretty much, is covered by stack scanning.
-Boris
Masquerade
May 7, 2012, 1:40:41 PM5/7/12
to
simply looking at the Spidermonkey process stack and looks for
something that looks like an address and that address so happen points
to a valid heap object? For one thing, to a process, the stack is
just an unstructured array of bytes. How does stack scanning knows a
function is referencing a JSObject? This is even no way we can tell
by looking at the stack that some particular 4 bytes are actually a
32bit pointer.
Boris Zbarsky
May 7, 2012, 2:31:07 PM5/7/12
to
On 5/7/12 1:40 PM, Masquerade wrote:
> Just curious. How does this stack scanning achieve its feat? Is it by
> simply looking at the Spidermonkey process stack and looks for
> something that looks like an address and that address so happen points
> to a valid heap object?
Yep. It's a conservative scanner. It might fail to callect things that
> Just curious. How does this stack scanning achieve its feat? Is it by
> simply looking at the Spidermonkey process stack and looks for
> something that looks like an address and that address so happen points
> to a valid heap object?
are actually collectable if there's an int on the stack that happens to
have the same value as an object address.
-Boris
0 new messages