How to update globals on a SES Compartment

[chetbox]

If I create a new Compartment how can I later update the globals available in the compartment?

const compartment = new Compartment({ foo: 1, bar: 2 });

Compartment has a getter for the global object but no setter:

  export class Compartment {
    // ...
    get globalThis(): Record<PropertyKey, any>;

My use case is I have a number of constants which may change every time a program is executed within the compartment. Rather than constructing a new Compartment for every execution, which may happen thousands of times every second, I believe it would be much more efficient to re the compartment and update the global object instead.

[kriskowal]

The chief consideration needed to answer this question is whether each program is running on the behalf of the same agent. If the global is mutable, each process (evaluation of a program) has an opportunity to interfere with every subsequent process by modifying or even freezing the environment. If the parameters are communicated as properties of a mutable global object, they can interfere by setting and then freezing the global object.

You can make a single compartment safe for multiple agents by freezing compartment.globalThis and providing no module loader hooks or any other endowments. Then, you can safely evaluate any number of subsequent programs without any possibility of interference through object manipulation. You would need an alternative mechanism for injecting configuration, different from manipulating globals, and you have many options. For example, you can obligate the program to return a function that you call with a configuration object.

compartment.evaluate(`(params) => {}`)(params);

You can also provide parameters as lexical bindings with a confined Function.

new compartment.globalThis.Function(...Object.keys(params), program)(...Object.values(params))

You can also preserve a Compartment with a mutable global for each agent you interact with, in which case they can only foul their own sandbox.

But, each new Compartment is very light by design, so you might in fact get away with instantiating them and throwing them away for every evaluation. I suggest at least measuring.

[chetbox]

Thanks for this! I didn't know you could do that.

Firstly, benchmarking this there's a penalty to:

1. Iterating the keys of the params object for every function execution. (Note that in our system the params change but the script that runs does not.) With a params object of 5 properties there's a function execution penalty of ~10-20x vs setting a global with new Compartment({ __options: true, global: params }).
2. Parsing and compiling program before every execution. For example a program of 2.5kB incurs a runtime penalty of 20-30x vs creating a function ahead of time.

Our use case is replacing the JEXL expression language with Javascript. The code our users write can be run thousands of times per second. JEXL has a notion

What we're trying to achieve is an efficient way to compile the program, which can get quite complex, just once. The program will give different results when executed with different global values available.

Our current system uses a Proxy as the global which lazily fetches the value when requested.
Note: The globals are immutable.

This would be much more efficient and simpler if we could set globals after the fact. Ideally we'd be able to do something like this:

const compartment = new Compartment()
const getValue = new compartment.globalThis.Function(`return (${myExpression}`)

const globals1 = getLatestGlobalValues() // A Proxy object with lazy getters for all values
compartment.setGlobals(globals1)
const result1 = getValue.call(undefined) // This can access globals from globals1

// later

const globals2 = getLatestGlobalValues()
compartment.setGlobals(globals2)
const result2 = getValue.call(undefined)

Is something like this possible with SES?

[chetbox]

I have found I can simply use the following to update globals available within SES:

for (const [key, value] of Object.entries(globals1)) {
  compartment.globalThis[key] = value;
}

I had assumed I could not do this because globalThis is a getter but I'm glad it works!

[mhofman]

Note: The globals are immutable.

This would be much more efficient and simpler if we could set globals after the fact. Ideally we'd be able to do something like this:

I'm a little confused by these 2 statements in juxtaposition. Are you saying the values on the global are immutable (I assume deeply frozen), but the global itself remains mutable?

What we're trying to achieve is an efficient way to compile the program, which can get quite complex, just once. The program will give different results when executed with different global values available.

This is an interesting problem if you want the execution to be fully isolated from each other. In theory we could imagine a way to substitute the global object itself (or as you're doing, properties of the global object). However nothing guarantees that the code you're executing will not create jobs that will continue execution asynchronously. At that point the "old call" would start seeing the new global values. One mitigation would be to deny any API in the compartment that can run a new task (e.g. setTimeout, FinalizationRegistry, etc.), and make sure that you schedule 2 consecutive independent calls of the compartment using a new task (to make sure all promise jobs / microtasks the execution might have created have been drained).

[chetbox]

Ah yes, I can see how this would be confusing.
In our system all code must be synchronous. I'll need to carefully disable anything that allows async operations and deferred execution.

The globals are immutable values but the values change every time the script is run so the resulting behaviour is different.

I hope that's a bit clearer!

[mhofman]

How do you prevent async operations? async / await is part of the syntax.

[chetbox]

I haven't got that far yet...! I can prevent access to setTimeout, Promise, etc I believe?
While async/await are allowed as part of the syntax I think if there's no way to defer execution then all programs are guaranteed to be synchronous.