Success with embedding ESR52 spidermonkey

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Success with embedding ESR52 spidermonkey

Kent Williams
In case anyone else follows my particular path (going from ESR45 to
ESR52)  Thanks to Steve Fink and #JSAPI personage ptomato-M

The biggest problem with doing this is the source code is the only
up-to-date documentation.  That's an ongoing Spidermonkey issue.

But the changes from JS45->JS52 are smaller than the last upgrade from
JS38->JS45 which had some drastic and mystifying API changes that took a
lot more support on the IRC to resolve.

Necessary changes. These might be a subset of what you'll need to do:

1. JSRuntime is no more.

2. JSClass has changed. The initialization is roughly like this below.
Basically the array of class functions is moved out of the JSClass into
a separate JSClassOps structure.

JSClass ScriptData::global_class = {
-    "global", JSCLASS_GLOBAL_FLAGS,
-    0,                                      // JSPropertyOp       
addProperty;
-    0,                                      // JSDeletePropertyOp 
delProperty;
-    0,                                      // JSPropertyOp       
getProperty;
-    0,                                      // JSStrictPropertyOp 
setProperty;
-    0,                                      // JSEnumerateOp      
enumerate;
-    0,                                      // JSResolveOp         resolve;
-    0,                                      // JSConvertOp         convert;
-    0,                                      // FinalizeOpType     
finalize;
-    0,                                      // JSNative            call;
-    0,                                      // JSHasInstanceOp    
hasInstance;
-    0,                                      // JSNative           
construct;
-    JS_GlobalObjectTraceHook,      // JSTraceOp           trace
-};
-
+static const JSClassOps global_ops = {
+    /* Function pointer members (may be null). */
+    nullptr,                              // JSAddPropertyOp addProperty;
+    nullptr,                              // JSDeletePropertyOp
delProperty;
+    nullptr,                              // JSGetterOp getProperty;
+    nullptr,                              // JSSetterOp setProperty;
+    nullptr,                              // JSEnumerateOp enumerate;
+    nullptr,                              // JSResolveOp resolve;
+    nullptr,                              // JSMayResolveOp mayResolve;
+    nullptr,                              // FinalizeOp finalize;
+    nullptr,                              // JSNative call;
+    nullptr,                              // JSHasInstanceOp hasInstance;
+    nullptr,                              // JSNative construct;
+    JS_GlobalObjectTraceHook,      // JSTraceOp           trace;
+};
+/* The class of the global object. */
+JSClass ScriptData::global_class = {
+    "global",
+    JSCLASS_GLOBAL_FLAGS,
+    &global_ops
+};
+

3. JS_NewContext no longer takes the runtime argument, and the size
argument is what the old JSRuntime init takes, e.g.
-        context = JS_NewContext(runtime, 8192);
+        context = JS_NewContext(8L * 1024L * 1024L);

4. Add JS::InitSelfHostedCode(context) after context initialization.

5. JS_SetErrorReporter is replaced by JS::SetWarningReporter.

6. JS::RootedString no longer allows JSRuntime as first argument, the
signature with a JSContext as first argument is used instead.

7. JSWarningReporter function signature is changed:

-void ScriptData::spidercode_error(JSContext *cx, const char *message,
-            JSErrorReport* what) {
+void ScriptData::spidercode_error(JSContext *cx,JSErrorReport* what) {

And insted of the 'message' parameter, use what->message()

8. Classes with FinalizeOp member need to specify either
JSCLASS_FOREGROUND_FINALIZE or JS_BACKGROUND_FINALIZE in the JSClass
flags field.


9. Linking: There's an ongoing problem related to static linking, the
ever-popular MOZ_GLUE_IN_PROGRAM bug.  There are various fixes proposed
for that if you look in Bugzilla@Mozilla which AFAIK don't end up in any
release yet.

I fixed it by force-loading all of the mozglue library on link:
-  -lmozglue
+  -Wl,--whole-archive -lmozglue -Wl,--no-whole-archive

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Success with embedding ESR52 spidermonkey

Benjamin Bouvier-2
Thank you Kent, that is great to read!

Note that in general, the Spidermonkey team won't update the documentation
on MDN whenever an API change breaks the code, because (this is going to be
deceptive but) there is nobody who is working on embedding (including
documentation) per se, and Spidermonkey priorities have not been moving
towards this direction, so far (this may or may not change in the future).

That being said, people are usually very happy to help and explain anything
about embedding on IRC (#jsapi on irc.mozilla.org), or to answer
questions/issues in bugs on Bugzilla.

Spidermonkey (Mozilla in general) is also a community project, so help like
the one you provide in this email is much helpful. Our documentation is
hosted on our wiki [1] and can be updated by *anyone*, as long as you sign
in (with Github 🤷).

So Kent, and anybody who stumbled upon SM embedding and found solutions to
their problems, I encourage you to update the wiki pages with your
solutions / fixes, so that other people don't run into them as well. That
would be greatly appreciated and I am pretty sure people from the JS team
would review and tweak the text, if needed. Thanks again!

Cheers,
Benjamin

[1]
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_User_Guide

2017-09-28 0:17 GMT+02:00 Kent Williams <[hidden email]>:

> In case anyone else follows my particular path (going from ESR45 to
> ESR52)  Thanks to Steve Fink and #JSAPI personage ptomato-M
>
> The biggest problem with doing this is the source code is the only
> up-to-date documentation.  That's an ongoing Spidermonkey issue.
>
> But the changes from JS45->JS52 are smaller than the last upgrade from
> JS38->JS45 which had some drastic and mystifying API changes that took a
> lot more support on the IRC to resolve.
>
> Necessary changes. These might be a subset of what you'll need to do:
>
> 1. JSRuntime is no more.
>
> 2. JSClass has changed. The initialization is roughly like this below.
> Basically the array of class functions is moved out of the JSClass into a
> separate JSClassOps structure.
>
> JSClass ScriptData::global_class = {
> -    "global", JSCLASS_GLOBAL_FLAGS,
> -    0,                                      // JSPropertyOp
> addProperty;
> -    0,                                      // JSDeletePropertyOp
> delProperty;
> -    0,                                      // JSPropertyOp
> getProperty;
> -    0,                                      // JSStrictPropertyOp
> setProperty;
> -    0,                                      // JSEnumerateOp
> enumerate;
> -    0,                                      // JSResolveOp
> resolve;
> -    0,                                      // JSConvertOp
> convert;
> -    0,                                      // FinalizeOpType
> finalize;
> -    0,                                      // JSNative            call;
> -    0,                                      // JSHasInstanceOp
> hasInstance;
> -    0,                                      // JSNative
> construct;
> -    JS_GlobalObjectTraceHook,      // JSTraceOp           trace
> -};
> -
> +static const JSClassOps global_ops = {
> +    /* Function pointer members (may be null). */
> +    nullptr,                              // JSAddPropertyOp addProperty;
> +    nullptr,                              // JSDeletePropertyOp
> delProperty;
> +    nullptr,                              // JSGetterOp getProperty;
> +    nullptr,                              // JSSetterOp setProperty;
> +    nullptr,                              // JSEnumerateOp enumerate;
> +    nullptr,                              // JSResolveOp resolve;
> +    nullptr,                              // JSMayResolveOp mayResolve;
> +    nullptr,                              // FinalizeOp finalize;
> +    nullptr,                              // JSNative call;
> +    nullptr,                              // JSHasInstanceOp hasInstance;
> +    nullptr,                              // JSNative construct;
> +    JS_GlobalObjectTraceHook,      // JSTraceOp           trace;
> +};
> +/* The class of the global object. */
> +JSClass ScriptData::global_class = {
> +    "global",
> +    JSCLASS_GLOBAL_FLAGS,
> +    &global_ops
> +};
> +
>
> 3. JS_NewContext no longer takes the runtime argument, and the size
> argument is what the old JSRuntime init takes, e.g.
> -        context = JS_NewContext(runtime, 8192);
> +        context = JS_NewContext(8L * 1024L * 1024L);
>
> 4. Add JS::InitSelfHostedCode(context) after context initialization.
>
> 5. JS_SetErrorReporter is replaced by JS::SetWarningReporter.
>
> 6. JS::RootedString no longer allows JSRuntime as first argument, the
> signature with a JSContext as first argument is used instead.
>
> 7. JSWarningReporter function signature is changed:
>
> -void ScriptData::spidercode_error(JSContext *cx, const char *message,
> -            JSErrorReport* what) {
> +void ScriptData::spidercode_error(JSContext *cx,JSErrorReport* what) {
>
> And insted of the 'message' parameter, use what->message()
>
> 8. Classes with FinalizeOp member need to specify either
> JSCLASS_FOREGROUND_FINALIZE or JS_BACKGROUND_FINALIZE in the JSClass flags
> field.
>
>
> 9. Linking: There's an ongoing problem related to static linking, the
> ever-popular MOZ_GLUE_IN_PROGRAM bug.  There are various fixes proposed for
> that if you look in Bugzilla@Mozilla which AFAIK don't end up in any
> release yet.
>
> I fixed it by force-loading all of the mozglue library on link:
> -  -lmozglue
> +  -Wl,--whole-archive -lmozglue -Wl,--no-whole-archive
>
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Success with embedding ESR52 spidermonkey

Boris Zbarsky
In reply to this post by Kent Williams
On 9/27/17 6:17 PM, Kent Williams wrote:
> 5. JS_SetErrorReporter is replaced by JS::SetWarningReporter.

Note that this is part of the overall error reporting changes wherein
now exceptions will NOT be reported via this reporter function.
Embeddings should handle exceptions themselves by checking for them
after performing JSAPI operations and dealing accordingly.

-Boris
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine