Skip to main content

Visit Mozilla.org

Embedding SpiderMonkey

From MDC

This document explains how to embed SpiderMonkey, the Mozilla JavaScript engine, in your C/C++ program.

JavaScript is widely used for client-side scripts that run in the browser. But Mozilla's JavaScript engine is a library that can be linked into any C/C++ program, not just a browser. Many applications can benefit from scripting. These programs can execute JavaScript code from C using the SpiderMonkey API.

Contents

[edit] What SpiderMonkey does

The JavaScript engine compiles and executes scripts containing JavaScript statements and functions. The engine handles memory allocation for the objects needed to execute scripts, and it cleans up—garbage collects—objects it no longer needs.

SpiderMonkey supports versions 1.0 through 1.8 of the JavaScript language. JS 1.3 and later conform to the ECMAScript specification, ECMA 262-3. Later versions also contain Mozilla extensions such as array comprehensions and generators. SpiderMonkey also supports E4X (optionally).

The word JavaScript may bring to mind features such as event handlers (like onclick), DOM objects, window.open, and XMLHttpRequest. But in Mozilla, all of these features are actually provided by other components, not the SpiderMonkey engine itself. SpiderMonkey provides a few core JavaScript data types—numbers, strings, Arrays, Objects, and so on—and a few methods, such as Array.push. It also makes it easy for each application to expose some of its own objects and functions to JavaScript code. Browsers expose DOM objects. Your application will expose objects that are relevant for the kind of scripts you want to write. It is up to the application developer to decide what objects and methods are exposed to scripts.

[edit] Using the SpiderMonkey library

Your application can use SpiderMonkey like any other C/C++ library. To build SpiderMonkey from source, see SpiderMonkey Build Documentation. You can build SpiderMonkey as a static library or as a shared library.

Some platforms (such as Debian Linux) provide SpiderMonkey as a prebuilt package; this can be easier to install but harder to debug.

C/C++ code accesses SpiderMonkey via the JSAPI, by including the header "jsapi.h". The JSAPI provides functions for setting up the JavaScript runtime, compiling and executing scripts, creating and examining JavaScript data structures, handling errors, enabling security checks, and debugging scripts.

An overview of JSAPI functionality follows. For more details, see the JSAPI Reference.

[edit] Key Spidermonkey concepts

In order to run any JavaScript code in SpiderMonkey, an application must have three key elements: a JSRuntime, a JSContext, and a global object. This section describes what these things are. The next section explains how to set them up, using JSAPI functions.

Runtimes. A JSRuntime, or runtime, is the space in which the JavaScript variables, objects, scripts, and contexts used by your application are allocated. Every JSContext and every object in an application lives within a JSRuntime. They cannot travel to other runtimes or be shared across runtimes. Most applications only need one runtime.

Contexts. A JSContext, or context, is like a little machine that can do many things involving JavaScript code and objects. It can compile and execute scripts, get and set object properties, call JavaScript functions, convert JavaScript data from one type to another, create objects, and so on. Almost all JSAPI functions require a JSContext * as the first argument, just like most <stdio.h> functions require a FILE *.

There is a close association between contexts and threads. Simple, single-threaded applications can use a single context for everything. But each context can only do one thing at a time, so in a multithreaded applcation, only thread at a time should use any given context. Such an application typically has one context per thread. JavaScript objects, on the other hand, are not permanently associated with the script, thread, or context that created them. They can be shared among many scripts or even many threads, as shown in the figure below.

Figure 1.1 illustrates the relationship of scripts to the runtime, contexts, and objects.

Figure 1.1

Image:Over3.gif

Global objects. Lastly, the global object contains all the classes, functions, and variables that are available for JavaScript code to use. Whenever JavaScript code does something like window.open("http://www.mozilla.org/"), it is accessing a global property, in this case window. JSAPI applications have full control over what global properties scripts can see. The application starts out by creating an object and populating it with the standard JavaScript classes, like Array and Object. Then it adds whatever custom classes, functions, and variables (like window) the application wants to provide; see Custom objects below. Each time the application runs a JS script (using, for example, JS_EvaluateScript), it provides the global object for that script to use. As the script runs, it can create global functions and variables of its own. All of these functions, classes, and variables are stored as properties of the global object.

[edit] JSAPI basics

Each of the three key elements described in the previous section requires a few JSAPI calls:

  • The runtime: Use JS_NewRuntime to create it and JS_DestroyRuntime to clean it up when you're done. When your application is done with SpiderMonkey altogether, use JS_ShutDown to free any remaining cached resources. (This is a mere nicety if the process is about to exit anyway. But as that is not always the case, calling JS_Shutdown is a good habit to get into.)
  • The global object: To create this object, you first need a JSClass with the JSCLASS_GLOBAL_FLAGS option. The example below defines a very basic JSClass (named global_class) with no methods or properties of its own. Use JS_NewObject to create a global object. Use JS_InitStandardClasses to populate it with the standard JavaScript globals.

This may seem like a lot of pieces for a simple application. It amounts to about 50 lines of code, as shown below. But the JSAPI is designed to scale to applications that need many threads, many contexts, and many global objects. It is a fine-grained API, supporting many different combinations of the parts, and giving applications precise control over how SpiderMonkey behaves.

Here is the boilerplate code necessary for a minimal JSAPI application. It contains everything described above. 

#include "jsapi.h"

/* The class of the global object. */
static JSClass global_class = {
    "global", JSCLASS_GLOBAL_FLAGS,
    JS_PropertyStub, JS_PropertyStub, JS_PropertyStub, JS_PropertyStub,
    JS_EnumerateStub, JS_ResolveStub, JS_ConvertStub, JS_FinalizeStub,
    JSCLASS_NO_OPTIONAL_MEMBERS
};

int main(int argc, const char *argv[])
{
    /* JS variables. */
    JSRuntime *rt;
    JSContext *cx;
    JSObject  *global;

    .
    .
    .

    /* Create a JS runtime. */
    rt = JS_NewRuntime(8L * 1024L * 1024L);
    if (rt == NULL)
        return 1;

    /* Create a context. */
    cx = JS_NewContext(rt, 8192);
    if (cx == NULL)
        return 1;
    JS_SetOptions(cx, JSOPTION_VAROBJFIX);

    /* Create the global object. */
    global = JS_NewObject(cx, &global_class, NULL, NULL);
    if (global == NULL)
        return 1;

    /* Populate the global object with the standard globals,
       like Object and Array. */
    if (!JS_InitStandardClasses(cx, global))
        return 1;

    .
    .
    .

    /* Your application code here. This may include JS API calls
       to create your own custom JS objects and run scripts. */

    .
    .
    .

    /* Cleanup. */
    JS_DestroyContext(cx);
    JS_DestroyRuntime(rt);
    JS_ShutDown();
    return 0;
}

[edit] JSContext

Almost all JS API calls require you to pass a context as an argument. A context identifies a script in the JavaScript engine. The engine passes context information to the thread that runs the script. Each simultaneously-executing script must be assigned a unique context. When a script completes execution, its context is no longer in use, so the context can be reassigned to a new script, or it can be freed.

To create a new context for a script, use JS_NewContext. This function takes two arguments: a pointer to the run time with which to associate this context, and the number of bytes of stack space to allocate for the context. If successful, the function returns a pointer to the newly established context. For example: 

 JSContext *cx;
 .
 .
 .
 cx = JS_NewContext(rt, 8192);

The run time must already exist. The stack size you specify for the context should be large enough to accommodate any variables or objects created by the script that uses the context. Note that because there is a certain amount of overhead associated with allocating and maintaining contexts you will want to:

  1. Create only as many contexts as you need at one time in your application.
  2. Keep contexts for as long as they may be needed in your application rather than destroying and recreating them as needed.

When a context is no longer needed, it should be destroyed to free its memory resources for other application uses. Depending on the scope of JS use in your application, you may choose to destroy the context immediately after its use, or, more likely, you may choose to keep the context available for reuse until your application is ready to terminate. In either case, use the JS_DestroyContext to free the context when it is no longer needed. This function takes a single argument, the pointer to the context to destroy: 

 JS_DestroyContext(cx);

If your application creates multiple run times, the application may need to know which run time a context is associated with. In this case, call JS_GetRuntime, and pass the context as an argument. JS_GetRuntime returns a pointer to the appropriate run time if there is one: 

 rt = JS_GetRuntime(cx);

When you create a context, you assign it stack space for the variables and objects that get created by scripts that use the context. You can also store large amounts of data for use with a given context, yet minimize the amount of stack space you need. Call JS_SetContextPrivate to establish a pointer to private data for use with the context, and call JS_GetContextPrivate to retrieve the pointer so that you can access the data. Your application is responsible for creating and managing this optional private data.

To create private data and associate it with a context:

  1. Establish the private data as you would a normal C void pointer variable.
  2. Call JS_SetContextPrivate, and specify the context for which to establish private data, and specify the pointer to the data.

For example: 

 JS_SetContextPrivate(cx, pdata);

To retrieve the data at a later time, call JS_GetContextPrivate, and pass the context as an argument. This function returns the pointer to the private data: 

 pdata = JS_GetContextPrivate(cx);

[edit] Initializing built-in and global JS objects

The JavaScript engine provides several built-in objects that simplify some of your development tasks. For example, the built-in Array object makes it easy for you to create and manipulate array structures in the JS engine. Similarly, the Date object provides a uniform mechanism for working with and handling dates. For a complete list of built-in objects supported in the engine, see the reference entry for JS_InitStandardClasses.

The JS engine always uses function and global objects. In general, the global object resides behind the scenes, providing a default scope for all other JS objects and global variables you create and use in your applications. Before you can create your own objects, you will want to initialize the global object. The function object enables objects to have and call constructors.

A single API call, JS_InitStandardClasses, initializes the global and function objects and the built-in engine objects so that your application can use them: 

if (!JS_InitStandardClasses(cx, global))
    return JS_FALSE;  /* Initialization failed. */

JS_InitStandardClasses returns JS_FALSE if initialization fails.

You can specify a different global object for your application. For example, the Firefox browser uses its own global object, window. To change the global object for you application, call JS_SetGlobalObject.

[edit] Creating and initializing custom objects

In addition to using the engine's built-in objects, you will create, initialize, and use your own JS objects. This is especially true if you are using the JS engine with scripts to automate your application. Custom JS objects can provide direct program services, or they can serve as interfaces to your program's services. For example, a custom JS object that provides direct service might be one that handles all of an application's network access, or might serve as an intermediary broker of database services. Or a JS object that mirrors data and functions that already exist in the application may provide an object-oriented interface to C code that is not otherwise, strictly-speaking, object-oriented itself. Such a custom object acts as an interface to the application itself, passing values from the application to the user, and receiving and processing user input before returning it to the application. Such an object might also be used to provide access control to the underlying functions of the application.

There are two ways to create custom objects that the JS engine can use:

  • Write a JS script that creates an object, its properties, methods, and constructor, and then pass the script to the JS engine at run time.
  • Embed code in your application that defines the object's properties and methods, call the engine to initialize a new object, and then set the object's properties through additional engine calls. An advantage of this method is that your application can contain native methods that directly manipulate the object embedding.

In either case, if you create an object and then want it to persist in the run time where it can be used by other scripts, you must root the object by calling JS_AddRoot or JS_AddNamedRoot. Using these functions ensures that the JS engine will keep track of the objects and clean them up during garbage collection, if appropriate.

[edit] Creating an object from a script

One reason to create a custom JS object from a script is when you only need an object to exist as long as the script that uses it is executing. To create objects that persist across script calls, you can embed the object code in your application instead of using a script.

Note: You can also use scripts to create persistent objects, too.

To create a custom object using a script:

  1. Define and spec the object. What is it intended to do? What are its data members (properties)? What are its methods (functions)? Does it require a run time constructor function?
  2. Code the JS script that defines and creates the object. For example: function myfun(){ var x = newObject(); . . . } NOTE: Object scripting using JavaScript occurs outside the context of embedding the JS engine in your applications. For more information about object scripting, see the Client-Side JavaScript Guide and the Server-Side JavaScript Guide. Embed the appropriate JS engine call(s) in your application to compile and execute the script. You have two choices: 1.) compile and execute a script with a single call to JS_EvaluateScript, JS_EvaluateUCScript or 2.) compile the script once with a call to JS_CompileScript or JS_CompileUCScript, and then execute it repeatedly with individual calls to JS_ExecuteScript. The "UC" versions of these calls provide support for Unicode-encoded scripts.

An object you create using a script only can be made available only during the lifetime of the script, or can be created to persist after the script completes execution. Ordinarily, once script execution is complete, its objects are destroyed. In many cases, this behavior is just what your application needs. In other cases, however, you will want object persistence across scripts, or for the lifetime of your application. In these cases you need to embed object creation code directly in your application, or you need to tie the object directly to the global object so that it persists as long as the global object itself persists.

[edit] Custom objects

Embedding a custom JS object in an application is useful when object persistence is required or when you know that you want an object to be available to several scripts. For example, a custom object that represents a user's ID and access rights may be needed during the entire lifetime of the application. It saves overhead and time to create and populate this object once, instead of recreating it over and over again with a script each time the user's ID or permissions need to be checked.

One way to embed a custom object in an application is to:

  1. Create a JSPropertySpec data type, and populate it with the property information for your object, including the name of the property's get and set methods.
  2. Create a JSFunctionSpec data type, and populate it with information about the methods used by your object.
  3. Create the actual C functions that are executed in response to your object's method calls.
  4. Call to JS_NewObject or JS_ConstructObject to instantiate the object.
  5. Call JS_DefineFunctions to create the object's methods.
  6. Call JS_DefineProperties to create the object's properties.

The code that describes persistent, custom JS objects should be placed near the start of application execution, before any code that relies upon the prior existence of the object. Embedded engine calls that instantiate and populate the custom object should also appear before any code that relies on the prior existence of the object.

Note: An alternate, and in many cases, easier way to create a custom object in application code is to call JS_DefineObject to create the object, and then make repeated calls to JS_SetProperty to set the object's properties. For more information about defining an object, see JS_DefineObject . For more information about setting an object's properties, see JS_SetProperty.

[edit] Providing private data for objects

Like contexts, you can associate large quantities of data with an object without having to store the data in the object itself. Call JS_SetPrivate to establish a pointer to private data for the object, and call JS_GetPrivate to retrieve the pointer so that you can access the data. Your application is responsible for creating and managing this optional private data.

To create private data and associate it with an object:

  1. Establish the private data as you would a normal C void pointer variable.
  2. Call JS_SetPrivate, specify the object for which to establish private data, and specify the pointer to the data.

For example: 

 JS_SetPrivate(cx, obj, pdata);

To retrieve the data at a later time, call JS_GetPrivate, and pass the object as an argument. This function returns the pointer to an object's private data: 

 pdata = JS_GetPrivate(cx, obj);

[edit] Handling Unicode

The JS engine now provides Unicode-enabled versions of many API functions that handle scripts, including JS functions. These functions permit you to pass Unicode-encoded scripts directly to the engine for compilation and execution. The following table lists standard engine functions and their Unicode equivalents:

Standard Function Unicode-enabled Function
JS_DefineProperty JS_DefineUCProperty
JS_DefinePropertyWithTinyId JS_DefineUCPropertyWithTinyId
JS_LookupProperty JS_LookupUCProperty
JS_GetProperty JS_GetUCProperty
JS_SetProperty JS_SetUCProperty
JS_DeleteProperty2 JS_DeleteUCProperty2
JS_CompileScript JS_CompileUCScript
JS_CompileScriptForPrincipals JS_CompileUCScriptForPrincipals
JS_CompileFunction JS_CompileUCFunction
JS_CompileFunctionForPrincipals JS_CompileUCFunctionForPrincipals
JS_EvaluateScript JS_EvaluateUCScript
JS_EvaluateScriptForPrincipals JS_EvaluateUCScriptForPrincipals
JS_NewString JS_NewUCString
JS_NewStringCopyN JS_NewUCStringCopyN
JS_NewStringCopyZ JS_NewUCStringCopyZ
JS_InternString JS_InternUCString
-- JS_InternUCStringN

Unicode-enabled functions work exactly like their traditional namesakes, except that where traditional functions take a char * argument, the Unicode versions take a jschar * argument.

[edit] Working with JS data types

JavaScript defines its own data types. Some of these data types correspond directly to their C counterparts. Others, such as JSObject, jsdouble, and JSString, are specific to JavaScript.

Generally, you declare and use JS data types in your application just as you do standard C data types. The JS engine, however, keeps separate track of JS data type variables that require more than a word of storage: JSObject, jsdouble, and JSString. Periodically, the engine examines these variables to see if they are still in use, and if they are not, it garbage collects them, freeing the storage space for reuse.

Garbage collection makes effective reuse of the heap, but overly frequent garbage collection may be a performance issue. You can control the approximate frequency of garbage collection based on the size of the JS run time you allocate for your application in relation to the number of JS variables and objects your application uses. If your application creates and uses many JS objects and variables, you may want to allocate a sufficiently large run time to reduce the likelihood of frequent garbage collection.

NOTE: Your application can also call JS_GC or JS_MaybeGC to force garbage collection at any time. JS_GC forces garbage collection. JS_MaybeGC performs conditional garbage collection only if a certain percentage of space initially allocated to the run time is in use at the time you invoke the function.

[edit] Working with JS Values

Main article: jsval

JavaScript is a dynamically typed language: variables and properties do not have a type that is fixed at compile time. How can a statically typed language, like C or C++, in which all variables have types, interact with JavaScript? The JSAPI provides a data type, jsval, which can contain JavaScript values of any type. A jsval could be a number, a string, a boolean value, a reference to an object (like an Object, Array, Date, or Function), or one of the special values null or undefined.

For integers and boolean values, a jsval contains the value itself. In other cases, the jsval is a pointer to the object, string, or number. A jsval variable fits in the same amount of memory as any other pointer. Using jsvals improves engine efficiency, and permits many API functions to handle a variety of underlying data types.

The JSAPI includes macros that test the JavaScript data type of a jsval. These are:

You can also test the value pointed to by a jsval to see if it is null (JSVAL_IS_NULL) or undefined (JSVAL_IS_VOID).

If a jsval points to a JS data type of JSObject, jsdouble, or JSString, you can cast the jsval to its underlying data type using JSVAL_TO_OBJECT, JSVAL_TO_DOUBLE, and JSVAL_TO_STRING, respectively. This is useful in some cases where your application or a JS engine call requires a variable or argument of a specific data type, rather than a jsval. Similarly, you can convert a JSObject, jsdouble, or JSString * to a jsval using OBJECT_TO_JSVAL, DOUBLE_TO_JSVAL, or STRING_TO_JSVAL.

[edit] Unicode string support

As with other API calls, the names of Unicode-enabled API string functions correspond one-for-one with the standard engine API string function names as follows: if a standard function name is JS_NewStringCopyN, the corresponding Unicode version of the function is JS_NewUCStringCopyN. Unicode-enabled API string functions are also available for interned string.

[edit] Interned strings

To save storage space, the JS engine provides support for sharing a single instance of a string among separate invocations. Such shared strings are called "interned strings". Use interned strings when you know that a particular, string of text will be created and used more than once in an application.

The engine API offers several calls for working with interned strings:

[edit] Security

SpiderMonkey is designed to support custom, application-defined security models. For example, the Firefox browser has a complex and powerful security model. Some JavaScript code ("chrome") has full access to the system. Scripts from web pages ("content") have very limited access. The same origin policy governs a script's access to data and functions from another web page.

The SpiderMonkey security model is based on the Java principals security model. This model provides a common security interface, but the actual security implementation is up to you.

To use SpiderMonkey's security features:

  • Decide what security policy you want to enforce.
  • Insert a call to JS_CheckAccess at each point in your application where a security check is necessary. (Some security checks are also built into the JavaScript engine; you must decide what security policy to enforce for each of these checks.)
  • Implement one or more JSPrincipals objects in your application. You need one JSPrincipals object for each different set of privileges that a script might have.
  • When compiling or executing code, use the JSAPI functions that attach principals to the compiled code. These functions have ForPrincipals in the name. They are listed below. The purpose of using these functions is to ensure that your access check callbacks have accurate information about who is trying to access an object.
  • Implement access check callback functions (see JSClass.checkAccess and JS_SetCheckObjectAccessCallback). These will be called from JS_CheckAccess and sometimes from within the JavaScript engine. An access check callback function can use jsdbgapi.h functions such as JS_FrameIterator and JS_StackFramePrincipals to obtain the principals of the code that is trying to perform the checked operation. Then it determines whether to allow the operation to proceed.
Function Purpose
JS_CompileScriptForPrincipals,
JS_CompileUCScriptForPrincipals,
JS_CompileFileHandleForPrincipals		 Compile a script with security information. (To execute a compiled script, use JS_ExecuteScript.)
JS_CompileFunctionForPrincipals,
JS_CompileUCFunctionForPrincipals		 Create a JavaScript function with security information.
JS_EvaluateScriptForPrincipals,
JS_EvaluateUCScriptForPrincipals		 Compile and execute a security-enabled script.
Retrieved from "http://developer.mozilla.org/en/docs/Embedding_SpiderMonkey"