0

According the Spidermonkey's User Guide

https://developer.mozilla.org/En/SpiderMonkey/JSAPI_User_Guide

... a jsval by itself does not protect its referent from the garbage collector...

My understanding of this statement is that if we create a JSString by, say, JS_NewStringCopyZ(), the value returned can be gc'ed at anytime. e.g.

JSString *str=JS_NewStringCopyZ(cx, "hello world");
JS_GC(cx);
//..now my "hello world" JSString is gone

So how do we prevent the str above from being gc'ed? I notice there is a JS_EnterLocalRootScope () function that I can call at the start of my JSNative function. Unfortunately, it is now deprecated. Then what should be the proper way to prevent gc?

JavaMan
  • 4,954
  • 4
  • 41
  • 69

1 Answers1

0

I think this is a duplicate of Garbage collector issues on spidermonkey… JS_AnchorPtr()? -- the answer there shows how to anchor pointers to keep them live across a GC when using SpiderMonkey as a shared library. If that doesn't answer your question, please edit to clarify.

Community
  • 1
  • 1
cdleary
  • 69,512
  • 53
  • 163
  • 191
  • No, that post is related to a deeper issue. Anyway, I've found my answer accidentally after discovering the comments in the jsapi.h about how the GC's conservative stack scanner works. Probably, the online JSAPI User Guide is outdated. It is still recommending people to root the JSString/JSVAL MANUALLY while at the same time indicating the JS_EnterLocalRootScope is obsolete. – JavaMan May 08 '12 at 07:31
  • 1
    You shouldn't rely on the conservative stack scanner. If you do and the engine switches to a moving collector, your code will break. – cdleary May 09 '12 at 19:27
  • cdleary is right, we are actively working on a moving collector--see http://blog.mozilla.org/dmandelin/2012/05/09/spidermonkey-api-futures/ – Dave Mandelin May 10 '12 at 01:24
  • @JavaMan: can you share the code which works for you? – Nathanael Weiss Mar 27 '14 at 21:19