## File: README.md

[](https://github.com/sebastienros/jint/actions/workflows/build.yml)
[](https://www.nuget.org/packages/Jint)
[](https://www.nuget.org/packages/Jint)
[](https://www.myget.org/feed/jint/package/nuget/Jint)
[](https://gitter.im/sebastienros/jint)

# Jint

Jint is a __Javascript interpreter__ for .NET which can run on __any modern .NET platform__ as it supports .NET Standard 2.0 and .NET 4.6.2 targets (and later).

## Use cases and users

- Run JavaScript inside your .NET application in a safe sand-boxed environment
- Expose native .NET objects and functions to your JavaScript code (get database query results as JSON, call .NET methods, etc.)
- Support scripting in your .NET application, allowing users to customize your application using JavaScript (like Unity games) 

Some users of Jint include 
[RavenDB](https://github.com/ravendb/ravendb), 
[EventStore](https://github.com/EventStore/EventStore), 
[OrchardCore](https://github.com/OrchardCMS/OrchardCore), 
[ELSA Workflows](https://github.com/elsa-workflows/elsa-core),
[docfx](https://github.com/dotnet/docfx), 
[JavaScript Engine Switcher](https://github.com/Taritsyn/JavaScriptEngineSwitcher),
and many more.

## Supported features

#### ECMAScript 2015 (ES6)

- ✔ ArrayBuffer
- ✔ Arrow function expression
- ✔ Binary and octal literals
- ✔ Class support
- ✔ DataView
- ✔ Destructuring
- ✔ Default, rest and spread
- ✔ Enhanced object literals
- ✔ `for...of`
- ✔ Generators
- ✔ Template strings
- ✔ Lexical scoping of variables (let and const)
- ✔ Map and Set
- ✔ Modules and module loaders
- ✔ Promises (Experimental, API is unstable)
- ✔ Reflect
- ✔ Proxies
- ✔ Symbols
- ✔ Proper tail calls in strict functions
- ✔ Typed arrays
- ✔ Unicode
- ✔ Weakmap and Weakset

Proper tail calls replace the calling strict-function frame, as required by ECMAScript. Consequently,
intermediate tail callers are intentionally absent from `error.stack` and host stack telemetry.

#### ECMAScript 2016

- ✔ `Array.prototype.includes`
- ✔ `await`, `async`
- ✔ Block-scoping of variables and functions
- ✔ Exponentiation operator `**`
- ✔ Destructuring patterns (of variables)

####  ECMAScript 2017

- ✔ `Object.values`, `Object.entries` and `Object.getOwnPropertyDescriptors`
- ✔ Shared memory and atomics

#### ECMAScript 2018

- ✔ Asynchronous iteration
- ✔ `Promise.prototype.finally`
- ✔ RegExp named capture groups
- ✔ Rest/spread operators for object literals (`...identifier`)
- ✔ SharedArrayBuffer

#### ECMAScript 2019

- ✔ `Array.prototype.flat`, `Array.prototype.flatMap`
- ✔ `String.prototype.trimStart`, `String.prototype.trimEnd`
- ✔ `Object.fromEntries`
- ✔ `Symbol.description`
- ✔ Optional catch binding

#### ECMAScript 2020

- ✔ `BigInt`
- ✔ `export * as ns from`
- ✔ `for-in` enhancements
- ✔ `globalThis` object
- ✔ `import`
- ✔ `import.meta`
- ✔ Nullish coalescing operator (`??`)
- ✔ Optional chaining
- ✔ `Promise.allSettled`
- ✔ `String.prototype.matchAll`

#### ECMAScript 2021

- ✔ Logical Assignment Operators (`&&=` `||=` `??=`)
- ✔ Numeric Separators (`1_000`)
- ✔ `AggregateError`
- ✔ `Promise.any` 
- ✔ `String.prototype.replaceAll`
- ✔ `WeakRef` 
- ✔ `FinalizationRegistry`

#### ECMAScript 2022

- ✔ Class Fields
- ✔ RegExp Match Indices
- ✔ Top-level await
- ✔ Ergonomic brand checks for Private Fields
- ✔ `.at()`
- ✔ Accessible `Object.prototype.hasOwnProperty` (`Object.hasOwn`)
- ✔ Class Static Block
- ✔ Error Cause

#### ECMAScript 2023

- ✔ Array find from last
- ✔ Change Array by copy
- ✔ Hashbang Grammar
- ✔ Symbols as WeakMap keys

#### ECMAScript 2024

- ✔ ArrayBuffer enhancements - `ArrayBuffer.prototype.resize` and `ArrayBuffer.prototype.transfer`
- ✔ `Atomics.waitAsync` 
- ✔ Ensuring that strings are well-formed - `String.prototype.ensureWellFormed` and `String.prototype.isWellFormed`
- ✔ Grouping synchronous iterables - `Object.groupBy` and `Map.groupBy`
- ✔ `Promise.withResolvers`
- ✔ Regular expression flag `/v`

#### ECMAScript 2025

- ✔ 16-bit floating point numbers (float16), Requires NET 8 or higher, `Float16Array`, `Math.f16round()`
- ✔ Array.fromAsync
- ✔ Import attributes
- ✔ Iterator helper methods 
- ✔ JSON modules
- ✔ `Promise.try`
- ✔ `RegExp.escape()`
- ✔ Regular expression pattern modifiers (inline flags)
- ✔ Duplicate named capture groups
- ✔ Set methods (`intersection`, `union`, `difference`, `symmetricDifference`, `isSubsetOf`, `isSupersetOf`, `isDisjointFrom`)

#### ECMAScript proposals (no version yet)

- ✔ Await Dictionary (`Promise.allKeyed`, `Promise.allSettledKeyed`)
- ✔ Decorators (`@decorator` syntax for classes, methods, fields, and accessors)
- ✔ `Error.isError`
- ✔ `Error.prototype.stack` accessor (error-stack-accessor)
- ✔ Explicit Resource Management (`using` and `await using`)
- ✔ Immutable Arraybuffers
- ✔ Import Bytes (`import x from './file' with { type: 'bytes' }`)
- ✔ Iterator Chunking (`Iterator.prototype.chunks`, `Iterator.prototype.windows`)
- ✔ Iterator Includes (`Iterator.prototype.includes`)
- ✔ Iterator Join (`Iterator.prototype.join`)
- ✔ Iterator Sequencing
- ✔ Joint Iteration
- ✔ JSON.parse source text access
- ✔ `Math.sumPrecise`
- ✔ `ShadowRealm`
- ✔ `Temporal`
- ✔ `Uint8Array` to/from base64
- ✔ `Upsert`

#### Other

- Further refined .NET CLR interop capabilities
- Constraints for execution (recursion, memory usage, duration)


## Performance

- Because Jint neither generates any .NET bytecode nor uses the DLR it runs relatively small scripts really fast
- If you repeatedly run the same script, you should prepare it for execution using `Engine.PrepareScript` or `Engine.PrepareModule`, cache the returned `Prepared<...>` object and feed it to Jint instead of the content string
- You should prefer running engine in strict mode, it improves performance

You can check out [the engine comparison results](Jint.Benchmark), bear in mind that every use case is different and benchmarks might not reflect your real-world usage.

## Embedding performance

Notes for hosts that project their own objects into script, pool engines, or bound execution. Each of these
is a cost model rather than a rule; the XML documentation on the named APIs has the detail.

**Projecting host data.** Subclassing `ObjectInstance` is the most expensive way to expose data. Such a
receiver gets no own-property inline caching — every own read reaches your `GetOwnProperty` and allocates the
`PropertyDescriptor` it returns. Cheaper options, in order of preference:

- For fixed-shape records, do not subclass at all: `JsObject.Create(engine, layout, values)` and
  `JsObject.CreateFromEntries` build straight into the hidden-class representation, so every object sharing a
  `JsObjectLayout` shares one hidden class and a script reading a batch of them keeps a monomorphic inline
  cache. A record with expensive members most items never have read — a body that must be parsed, a field that
  must be decoded — declares them with `JsObjectLayout.CreateBuilder().AddLazy(name, factory)` and passes the
  raw payload as the `lazySlotState` argument of `JsObject.Create`: the factory runs on the first read that
  observes that member's value and the result is memoized on the object, while enumerating keys, `in` and
  `hasOwnProperty` never run it. The object stays a hidden-class object throughout.
- For CLR objects, `engine.SetValue(name, obj)` wraps them in `ObjectWrapper`, whose member resolution and
  compiled accessors are cached process-wide on the `TypeResolver`.
- For the *prototypes* those objects sit behind, declare the members once per process with `JsObjectShape` and
  create one object per engine with `Instantiate`: members materialize only when a script touches them, and
  because the engine stores and versions the whole member set itself, a shaped prototype can serve the
  prototype-method inline cache — which an `ObjectInstance` subclass used as a prototype can never do.
- For a **live indexed collection** — a DOM `NodeList`, a result window, any list computed on demand — derive
  from `ArrayLikeObject` rather than assembling the property model yourself. You implement two members,
  `uint Length` and `bool TryGetIndex(uint index, out JsValue value)`; the base class derives everything else
  (index and `length` descriptors, enumeration order, the existence and value hooks, WebIDL-shaped `delete` /
  `defineProperty` refusals) and the engine keys two lanes on the type, so `list[i]`, `Array.prototype`
  generics, `for-of` / spread / `Array.from` / destructuring and `JSON.stringify` each cost one
  `TryGetIndex` per element with no descriptor and no key allocation. It is array-*like*, not an array:
  `Array.isArray` stays `false` by design, the same answer a browser gives for a `NodeList`. If your backing
  store can test containment more cheaply than it can produce an element, also override
  `protected virtual bool HasIndex(uint index)`, and `in` / `hasOwnProperty` / `Object.keys` / `delete` stop
  projecting elements they only ever discard. Reach for it when the collection is live; when it is a snapshot,
  copying into a `JsArray` once is cheaper still — and give it a `JsObjectShape` prototype, per the bullet
  above, for the collection's own methods.
- If you must subclass, override `TryGetOwnPropertyValue` so an own read hands the value over with no
  descriptor at all, and `ProbeOwnProperty` so existence and enumerability questions (`in`, `Object.keys`,
  spread, `JSON.stringify`) are answered without materializing one either. Both carry an obligation to agree
  with `GetOwnProperty`, and neither is re-verified on the hot path — a `ProbeOwnProperty` that wrongly reports
  a key as absent drops it from every enumeration, silently. Run your integration suite once with
  **host-contract verification** on and every such disagreement throws instead, naming the type, the key and
  both answers:

  ```csharp
  // before the first use of any Jint type — the flag is read once, at type initialization
  AppContext.SetSwitch("Jint.EnableHostContractVerification", true);
  ```

  It also checks a declared `PropertyAccessSemantics.Ordinary`, an `ArrayLikeObject`'s `HasIndex`, and an
  `IObjectConverter` registered with `AddObjectConverter(converter, handledTypes)` converting a type it did not
  declare. Turn it on in a test or staging host, never in production: the checks deliberately redo the work the
  hooks exist to avoid. A Debug build of Jint has them on already and needs no switch.

**Lazy values.** `PropertyFlag.CustomJsValue` is the supported hook for a property whose value is *computed on
every read*: a `PropertyDescriptor` subclass overriding `CustomValue` keeps working under the read inline
caches, because every caching lane re-reads the flag on each hit and caches the descriptor reference rather
than a value snapshot. When the value is lazy only *once*, use `PropertyDescriptor.CreateLazy(state, factory)`
instead — it memoizes the produced value and then stops being custom-valued, which readmits the property to the
member-write fast path and the global-identifier cache that a permanently custom-valued descriptor is declined
by; store it wherever you store descriptors (`SetOwnProperty` or `GetOwnProperty` on a host subclass,
`FastSetProperty`, a hand-rolled global). It is the descriptor-shaped member of the same family as
`JsObjectLayout.AddLazy` (records) and `JsObjectShape` (prototypes), and it does not exempt you from the rule
above them: storing any raw descriptor under a string key still moves a shape-mode object to the dictionary
representation. For a whole global that may never be touched, `Options.AddLazyGlobal` defers building
the value until script reads the name, and `engine.Advanced.AddLazyGlobal` does the same on an engine that
already exists — which is what you need when the value comes from the request you are about to serve rather
than from process-wide configuration. Both install the property eagerly, so `in`, `hasOwnProperty` and
`Object.keys(globalThis)` see the name without building anything; only reading the value runs the factory,
once. The per-engine overload receives its engine, so unlike an `Options`-registered factory it may capture
engine-affine state — and where it would do nothing but capture, the overload taking the state,
`engine.Advanced.AddLazyGlobal(name, state, static (e, s) => ...)`, hands it to a `static` factory instead.
That matters only because this registration is per engine: a capturing factory costs a display class and a
delegate for every global on every engine you build, which on `FreshEngineGlobalsBenchmark`'s forty-global
row is 32 bytes per global. There is deliberately no `Options` counterpart — a registration made there is
recorded once for the process and replayed per engine, so its closure is already a one-off.

**Per-request state behind an engine.** Every host-facing factory in this API receives the engine and nothing
else, which is a problem when the value depends on the request rather than on process-wide configuration.
`engine.Advanced.HostDefined` closes that gap: an opaque `object?` the engine never reads or interprets — the
`[[HostDefined]]` field the specification reserves on a Realm Record — so a factory that captures nothing can
still reach the scope it is running in. The alternative embedders reach for is a
`static ConditionalWeakTable<Engine, IServiceProvider>`, which takes its internal write lock every time a
host associates state with an engine, across every tenant in the process.

```c#
// once per process — the factory captures nothing, so one Options serves every engine
var options = new Options()
    .AddLazyGlobal("user", static engine =>
        JsValue.FromObject(engine, ((RequestContext) engine.Advanced.HostDefined!).User));

// per request, before you run anything
engine.Advanced.HostDefined = requestContext;
```

It is the *principal* realm's field, not the current one, so it answers the same value inside a `ShadowRealm`
callback as outside. A shadow realm is a distinct realm and gets its own, empty by specification — deliberate,
since propagating the outer request's services into sandboxed code is exactly the ambient authority a shadow
realm exists to withhold; `Host.InitializeShadowRealm` is the hook if you do want to populate it. The value
dies with the engine, and nothing in the engine clears it: a restore (below) does not touch it, so a pooled
engine keeps it across one and you replace it yourself, typically right after restoring.

**Sparse data.** Hosts that read deep chains off optional data — `input.Address.City.length`, where any link
may be absent — usually install an `IReferenceResolver` so a nullish base yields a value instead of throwing.
Register `NullPropagatingReferenceResolver.Instance` rather than writing that class yourself: the engine
recognizes the singleton and serves the propagation inline, with no interface call and no pooled `Reference`
per nullish read, which an equivalent hand-written resolver cannot get. Pass
`ReferenceResolverInterests.NullishPropertyBase` alongside it so every unrelated read lane stays armed. The
boundary is that *reads* propagate: a call on a nullish base still throws, and a host that needs callable
substitution or unresolvable-identifier handling writes its own resolver and forgoes the inline lane.

**Prepared scripts and engine reuse.** `Engine.PrepareScript` / `PrepareModule` return an object that is
reusable *and* thread-safe: prepare once at startup and feed the same `Prepared<T>` to as many engines, on as
many threads, as you like. The engine's own per-node caches are a separate matter — they are engine-owned and
engage only on the **second** evaluation of a given script on a given engine, so a host that builds a fresh
engine per operation never reaches them by design. Note the mirror image if you pool engines instead: a
warmed call site holds a reference to the last receiver it served until it caches a different one, so pooled
engines can keep host objects alive between runs.

**Sharing a module graph across pooled engines.** A host whose templates or plugins are ES modules pays for
that graph per engine: `IModuleLoader.LoadModule` is called by every engine that imports a module, so the
obvious loader re-reads and re-parses the whole graph for every engine in the pool. Prepare each module once
per *build* instead — cache the `Prepared<AstModule>` (`AstModule` being Acornima's `Module`, which an alias
keeps apart from Jint's runtime `Module`) keyed by module location, and hand it to the overload that takes an
already prepared AST, `ModuleFactory.BuildSourceTextModule(engine, in prepared)`. Name the prepared module
exactly as the engine would: `Engine.PrepareModule(code, source)` takes the name up front, and it becomes
`Module.Location` and therefore the `referencingModuleLocation` echoed back into `IModuleLoader.Resolve` for
that module's own imports — so a name derived by hand that differs from the engine's breaks relative-import
resolution with nothing to point at. `ModuleFactory.LocationOf(resolved)` *is* that rule; call it rather than
reimplementing it.

Single-flight the cache. `ConcurrentDictionary.GetOrAdd` does not run its factory under a lock, so N engines
filling a pool concurrently each prepare the same module and N-1 results are prepared only to be discarded.
Wrapping the value in a `Lazy<T>` — whose default thread-safety mode is exactly "one factory run, everyone
else waits" — is enough:

```c#
using AstModule = Acornima.Ast.Module; // Jint.Runtime.Modules.Module is a different type

private readonly ConcurrentDictionary<string, Lazy>> _prepared
    = new(StringComparer.Ordinal);

public Module LoadModule(Engine engine, ResolvedSpecifier resolved)
{
    var location = ModuleFactory.LocationOf(resolved);
    var prepared = _prepared.GetOrAdd(location,
        static key => new Lazy>(() => Engine.PrepareModule(ReadSource(key), key))).Value;

    return ModuleFactory.BuildSourceTextModule(engine, in prepared);
}
```

Invalidate by build, not by file. The prepared ASTs are derived from a compilation, so key the cache to the
same identity the rest of your host already uses for that compilation and let a rebuild drop the whole set at
once, rather than expiring entries per file and serving a graph half of which is stale.

Be clear about what the thread-safety of `Prepared<T>` buys. It is safe to share and safe to run concurrently,
which is what lets one cache serve the pool — it does not make the *engines* shareable (one engine, one
thread) and it does not make the module registry shared: every engine still builds, links and evaluates its
own module records from the shared ASTs, and `engine.Modules` is per engine. That per-engine cost is real, and
it is what the pool pays no matter how much preparation is shared.

`StaticAnalysis` is a trade with a break-even, not a speed-up. Preparing with
`new ModulePreparationOptions { StaticAnalysis = false }` skips the pass that pre-publishes interpreter state
onto the parsed tree, leaving preparation at roughly the cost of a plain parse; each engine then rebuilds
lazily what the pass would have published once for all of them. Measured on `ModuleGraphEmbeddingBenchmark`'s
ten-module graph, preparation cost -47.6% time and -27.5% allocation, while each engine materializing that
graph from the shared cache paid +4.8% time and +9.5% allocation — break-even, on that graph, at about ten
engines on time and about two on allocation. A long-lived pool should therefore keep the default (`true`);
the option is for preparation that sits on a latency-critical path — a cold start, a rebuild in a dev loop —
or for a host whose prepared programs outnumber the engines that ever run them.
`ScriptPreparationOptions.StaticAnalysis` is the same option for scripts.

**Registering only what a script uses.** When the ambient API is large and scripts touch little of it,
prepare with `ScriptPreparationOptions.CollectReferencedGlobals` and read `Prepared<T>.ReferencedGlobals`:
the free identifiers the program actually references, resolved per binding site, as an immutable set you can
intersect with your registry — including the CLR-side context you would otherwise build speculatively, which
lazy globals cannot defer. Honor `HasDirectEvalCall`: a program with direct `eval` can reference anything,
so install everything for those.

**Reusing a configured engine.** If you build a fresh engine per evaluation only because you need a clean
global, `engine.Advanced.CaptureGlobalSnapshot()` and `RestoreGlobalSnapshot(snapshot)` are the cheaper route:
capture once after your `SetValue` calls and module setup, then restore between evaluations. Restore reverts
the global object's own properties, its prototype and extensibility, and the top-level `let`/`const`/`class`
declarations (which nothing else can clear, so a script with a top-level `let` can otherwise only be run once
per engine); it also clears the `RegExp.$1`-style legacy statics and resets the interop wrapper caches. The
per-node caches above are deliberately kept, so the next run starts warm. Keep the snapshot in a field beside
the engine and put the restore in a `finally` — a script that throws still declared its globals, so restoring
only on the success path hands them to the next caller. `engine.Advanced.WithRestoredGlobals(snapshot, action)`
is exactly that `try`/`finally` in one call, so the restore cannot be left off the throwing path; it adds
nothing else, and in particular no isolation the restore does not already give you.

Choosing between this and `AddLazyGlobal` is a question of engine lifetime: a fresh-engine-per-evaluation
host wants lazy globals (nothing to restore — the win is never building what the script does not read); a
pooled host wants the snapshot. They compose: restore returns a global that was still lazy at capture to its
unmaterialized state, so a pooled engine keeps both benefits.

Restore also ends the previous cycle on the event loop. Queued jobs are discarded, and — because discarding
cannot reach work that has not been enqueued yet — any promise registered before the restore is dropped when
it settles instead of resuming its continuation, so a fire-and-forget `async` function suspended on a host
`Task` never wakes up against the restored globals. Register a promise that is meant to outlive a restore
*after* it. Restore refuses (`InvalidOperationException`) while an evaluation is in progress, including an
`EvaluateAsync`/`ExecuteAsync`/`InvokeAsync` whose `Task` you still hold. What it cannot fence is you calling
back in: invoking a function a previous evaluation handed you runs it against the restored surface.

**It is a configuration-reuse primitive, not an isolation boundary** — mutations of `Object.prototype` and
other intrinsics, of object graphs behind restored bindings, of host CLR state, plus `Symbol.for`
registrations and registered modules, all survive a restore, so mutually distrusting scripts still need
separate engines. Note that surviving intrinsic pollution is a surviving *binding*, not just a surviving
property: bare identifiers resolve through the global's prototype chain, so `Object.prototype.leaked = 1` in
one evaluation makes `leaked` a name the next one can read with no qualifier. (The global's own
`[[Prototype]]` is captured and restored, so a `setPrototypeOf(globalThis, …)` is reverted.) A snapshot also
keeps its engine and every captured value strongly reachable, so do not cache one past that engine's
lifetime.

**Constraints and options.** An `Options` instance is meant to be shared across engines, including concurrent
ones — the built-in constraint helpers register a *factory*, so each engine gets its own counter and its own
deadline. (Sharing it is not required: building an `Options` per scope is fine when your globals depend on
scoped state.) Watch for the sentinel trap: `MaxStatements(int.MaxValue)`, `LimitMemory(long.MaxValue)` and
`TimeoutInterval(TimeSpan.MaxValue)` register *no* constraint at all and remove any previously registered one
of that kind, so spelling "effectively unlimited" that way leaves you with no limit rather than a large one.

**Values do not cross engines.** A `JsValue` that is an `ObjectInstance` holds a hard reference to the engine
and realm that created it, and passing one to a different engine is not supported — it is neither validated
nor made safe. `Prepared<Script>` / `Prepared<Module>` and `ModuleBuilder` are the supported ways to share
work between engines; convert to CLR values (`ToObject()`) to move data.

## Discussion

Join the chat on [Gitter](https://gitter.im/sebastienros/jint) or post your questions with the `jint` tag on [stackoverflow](http://stackoverflow.com/questions/tagged/jint).

## Video

Here is a short video of how Jint works and some sample usage

https://docs.microsoft.com/shows/code-conversations/sebastien-ros-on-jint-javascript-interpreter-net

## Thread-safety

Engine instances are not thread-safe and they should not accessed from multiple threads simultaneously. 

## Examples

This example defines a new value named `log` pointing to `Console.WriteLine`, then runs
a script calling `log('Hello World!')`. 

```c#
var engine = new Engine()
    .SetValue("log", new Action<object>(Console.WriteLine));
    
engine.Execute(@"
    function hello() { 
        log('Hello World');
    };
 
    hello();
");
```

Here, the variable `x` is set to `3` and `x * x` is evaluated in JavaScript. The result is returned to .NET directly, in this case as a `double` value `9`. 
```c#
var square = new Engine()
    .SetValue("x", 3) // define a new variable
    .Evaluate("x * x") // evaluate a statement
    .ToObject(); // converts the value to .NET
```

You can also directly pass POCOs or anonymous objects and use them from JavaScript. In this example for instance a new `Person` instance is manipulated from JavaScript. 
```c#
var p = new Person {
    Name = "Mickey Mouse"
};

var engine = new Engine()
    .SetValue("p", p)
    .Execute("p.Name = 'Minnie'");

Assert.AreEqual("Minnie", p.Name);
```

You can invoke JavaScript function reference
```c#
var result = new Engine()
    .Execute("function add(a, b) { return a + b; }")
    .Invoke("add",1, 2); // -> 3
```
or directly by name 
```c#
var engine = new Engine()
   .Execute("function add(a, b) { return a + b; }");

engine.Invoke("add", 1, 2); // -> 3
```
## Accessing .NET assemblies and classes

You can allow an engine to access any .NET class by configuring the engine instance like this:
```c#
var engine = new Engine(cfg => cfg.AllowClr());
```

Then you have access to the `System` namespace as a global value. Here is how it's used in the context on the command line utility:
```javascript
jint> var file = new System.IO.StreamWriter('log.txt');
jint> file.WriteLine('Hello World !');
jint> file.Dispose();
```
And even create shortcuts to common .NET methods
```javascript
jint> var log = System.Console.WriteLine;
jint> log('Hello World !');
=> "Hello World !"
```

When allowing the CLR, you can optionally pass custom assemblies to load types from. 
```c#
var engine = new Engine(cfg => cfg
    .AllowClr(typeof(Bar).Assembly)
);
```

and then to assign local namespaces the same way `System` does it for you, use `importNamespace`
```javascript
jint> var Foo = importNamespace('Foo');
jint> var bar = new Foo.Bar();
jint> log(bar.ToString());
```    

adding a specific CLR type reference can be done like this
```csharp
engine.SetValue("TheType", TypeReference.CreateTypeReference(engine));
```

and used this way
```javascript
jint> var o = new TheType();
```

Generic types are also supported. Here is how to declare, instantiate and use a `List<string>`:
```javascript
jint> var ListOfString = System.Collections.Generic.List(System.String);
jint> var list = new ListOfString();
jint> list.Add('foo');
jint> list.Add(1); // automatically converted to String
jint> list.Count; // 2
```

### Intercepting access to .NET objects

ECMAScript Proxy traps can be implemented in .NET by deriving from `ProxyHandler` and creating the proxy via `engine.Advanced.CreateProxy` (or `CreateRevocableProxy`). A trap returning `null` forwards the operation to the target, exactly like an absent trap on a JavaScript handler object, and all proxy invariants are enforced on trap results. Combine with `SetWrapObjectHandler` to transparently intercept every wrapped .NET object. Note that `proxy.method()` fires the `Get` trap (then calls the returned value) — the `Apply` trap only fires when the proxy itself is invoked, so intercepting method calls means returning a wrapping function from `Get`. `new Proxy(target, handlerObject)` from script remains the JavaScript-side equivalent.

```c#
class LoggingHandler : ProxyHandler
{
    public override JsValue? Get(ObjectInstance target, JsValue property, JsValue receiver)
    {
        Console.WriteLine($"get {property}");
        return null; // forward to the target
    }

    public override bool? Has(ObjectInstance target, JsValue property)
    {
        Console.WriteLine($"has {property}");
        return null;
    }
}

var engine = new Engine(options =>
{
    // wrap every interop object in a logging proxy
    options.SetWrapObjectHandler((e, obj, type) =>
        e.Advanced.CreateProxy(ObjectWrapper.Create(e, obj, type), new LoggingHandler()));
});
```

## Internationalization

You can enforce what Time Zone or Culture the engine should use when locale JavaScript methods are used if you don't want to use the computer's default values.

This example forces the Time Zone to Pacific Standard Time.
```c#
var PST = TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time");
var engine = new Engine(cfg => cfg.LocalTimeZone(PST));
    
engine.Execute("new Date().toString()"); // Wed Dec 31 1969 16:00:00 GMT-08:00
```

This example is using French as the default culture.
```c#
var FR = CultureInfo.GetCultureInfo("fr-FR");
var engine = new Engine(cfg => cfg.Culture(FR));
    
engine.Execute("new Number(1.23).toString()"); // 1.23
engine.Execute("new Number(1.23).toLocaleString()"); // 1,23
```

### Extending Temporal and Intl with custom providers

Jint ships English-only / ISO-only defaults to keep the binary small. Non-English CLDR
data and full IANA timezone DST history are reachable via two pluggable providers:

| Extension point | Default | What it covers | Reusable example |
| --- | --- | --- | --- |
| `Options.Temporal.TimeZoneProvider` (`ITimeZoneProvider`) | `DefaultTimeZoneProvider` (BCL `TimeZoneInfo` + Windows↔IANA mapping) | UTC offsets, DST transitions, IANA canonicalization | [`NodaTimeZoneProvider.cs`](Jint.Tests.Test262/NodaTimeZoneProvider.cs) — uses NodaTime TZDB for full historical accuracy |
| `Options.Intl.CldrProvider` (`ICldrProvider`) | `DefaultCldrProvider` (English + .NET `CultureInfo`) | locale names, currencies, units, plural rules, calendar month/era names | [`IcuCldrProvider.cs`](Jint.Tests.Test262/IcuCldrProvider.cs) — uses ICU4N for full CLDR coverage |

The provider files in `Jint.Tests.Test262/` are **MIT-licensed copy-and-modify templates**,
not a stable API contract. They are also exactly how the test suite reaches its current
test262 conformance numbers.

To wire them into your project, add the same NuGet packages (`NodaTime`, `ICU4N`), copy
the provider files in, and register them on `Engine` options:

```c#
var engine = new Engine(options =>
{
    options.Temporal.TimeZoneProvider = new NodaTimeZoneProvider();
    options.Intl.CldrProvider          = new IcuCldrProvider();
});
```

A separate `ICalendarProvider` for non-ISO calendar arithmetic (Islamic UmAlQura, Persian
astronomical, Chinese/Dangi at extreme dates) is on the roadmap; until then non-ISO
calendars use `System.Globalization.Calendar` subclasses, which constrains some date
ranges (see [`Jint/Native/Temporal/NonIsoCalendars.cs`](Jint/Native/Temporal/NonIsoCalendars.cs)).

## Execution Constraints 

Execution constraints are used during script execution to ensure that requirements around resource consumption are met, for example:

* Scripts should not use more than X memory.
* Scripts should only run for a maximum amount of time.

You can configure them via the options:

```c#
var engine = new Engine(options => {

    // Limit memory allocations to 4 MB
    options.LimitMemory(4_000_000);

    // Set a timeout to 4 seconds.
    options.TimeoutInterval(TimeSpan.FromSeconds(4));

    // Set limit of 1000 executed statements.
    options.MaxStatements(1000);

    // Use a cancellation token.
    options.CancellationToken(cancellationToken);
}
```

You can also write a custom constraint by deriving from the `Constraint` base class:

```c#
public abstract class Constraint
{
    /// Called before script is run and useful when you use an engine object for multiple executions.
    public abstract void Reset();

    // Called before each statement to check if your requirements are met; if not - throws an exception.
    public abstract void Check();
}
```

For example we can write a constraint that stops scripts when the CPU usage gets too high:

```c#
class MyCPUConstraint : Constraint
{
    public override void Reset()
    {
    }

    public override void Check()
    {
        var cpuUsage = GetCPUUsage();

        if (cpuUsage > 0.8) // 80%
        {
            throw new OperationCancelledException();
        }
    }
}

var engine = new Engine(options =>
{
    options.Constraint(new MyCPUConstraint());
});
```

### Bounding an operation that makes several calls into the engine

Every call into the engine — `Execute`, `Evaluate`, `Invoke`, `Call` — is a complete run, and the engine
resets the constraints around each one. `TimeoutInterval` therefore bounds *one* call, not a sequence of
them: a loop such as `foreach (var row in rows) engine.Invoke("render", row);` gives every row the full
interval to itself, so the loop as a whole is unbounded.

When the thing you need to bound is your own operation — a whole render, a whole request — rather than one
call, use `OperationDeadlineConstraint`. Its budget is started and stopped by you, and the engine's
per-call reset leaves it alone:

```c#
// one instance per engine, and you keep the reference
var deadline = new OperationDeadlineConstraint();
var engine = new Engine(options => options.Constraint(deadline));

deadline.Begin(TimeSpan.FromSeconds(2), cancellationToken);
try
{
    foreach (var row in rows)
    {
        engine.Invoke("render", row);
    }
}
finally
{
    deadline.End();
}
```

The whole loop shares the two seconds. When it runs out, the next call fails with a `TimeoutException` —
the same exception the built-in timeout throws. If the token is cancelled, the call fails with a real
`OperationCanceledException` carrying that token, so cancellation you asked for stays distinguishable from
a script failure. Outside a `Begin`/`End` pair the constraint is inert, which makes it safe to leave
registered on a pooled engine between operations. The two constraints are independent, so you can keep a
`TimeoutInterval` as a per-call ceiling alongside it.

When you reuse the engine and want to use cancellation tokens you have to reset the token before each call of `Execute`:

```c#
var engine = new Engine(options =>
{
    options.CancellationToken(new CancellationToken(true));
});

var constraint = engine.Constraints.Find<CancellationConstraint>();

for (var i = 0; i < 10; i++) 
{
    using (var tcs = new CancellationTokenSource(TimeSpan.FromSeconds(10)))
    {
        constraint.Reset(tcs.Token);

        engine.SetValue("a", 1);
        engine.Execute("a++");
    }
}
```

### Surviving an unbounded recursion

A script that recurses without bound does not throw. It exhausts the native stack of the thread it is
running on, and that ends the host process: no exception, nothing to `catch`, nothing in the log but an
exit code. Every route into a function body can do it — a call, `new`, a getter or setter, a
`valueOf`/`toString` coercion, a Proxy trap, a callback a built-in invokes, a host delegate that calls
back into the engine.

```c#
var engine = new Engine(options =>
{
    options.Constraints.StackOverflowGuard = true;
});
```

With the guard on, every entry into a script function first checks that the native stack has not been used
up, and the same script raises `RangeError: Maximum call stack size exceeded` while there is still room to
unwind — an ordinary JavaScript error, catchable by the script itself and by your
`catch (JavaScriptException)`, with the engine still usable afterwards. It measures the remaining stack
rather than counting calls, so it covers all of those routes and adapts to the thread the engine runs on:
a host that provisions a larger stack gets proportionally more depth, rather than the frame count someone
had to guess in advance.

A proper tail call in a strict function is exempt, and does not need the guard: it replaces the caller's
frame instead of stacking one on top, so the recursion consumes no native stack however deep it runs. The
check sits on the entries that do add a frame, so a strict tail recursion neither pays for it nor is
stopped by it. Sloppy-mode recursion, a call out of tail position, and the non-call routes above are what
remain in scope.

It is off by default because the check runs at every entry into a script function and that is not free.
The benchmark gate measured recursion-heavy workloads (`Fib`, `DeepSum`, `Tak`) 1.7–2.3% slower with it
on, with hot shallow calls unaffected. Enable it when the engine runs script you did not write, where a
couple of percent on deep recursion in exchange for keeping your process is plainly the trade you want.
Leave it off when every script is yours and you can bound it yourself.

`options.LimitRecursion(n)` answers a different question and composes with it. The recursion limit counts
frames and is checked before the callee is entered, so where it is configured it is what fires; the guard
answers only when no limit was set, or when the limit was set higher than the thread's stack can actually
hold — which is easy to do by accident, since how many frames a stack holds is not something a host can
see. A third and older setting, `options.Constraints.MaxExecutionStackCount`, continues the call chain on
a fresh thread instead of throwing; it is checked at call expressions only, so it does not cover the other
routes above, and it takes precedence over the guard when both are set.

## Using Modules

You can use modules to `import` and `export` variables from multiple script files:

```c#
var engine = new Engine(options =>
{
    options.EnableModules(@"C:\Scripts");
});

var ns = engine.Modules.Import("./my-module.js");

var value = ns.Get("value").AsString();
```

By default, the module resolution algorithm will be restricted to the base path specified in `EnableModules`, and there is no package support. However you can provide your own packages in two ways.

Defining modules using JavaScript source code:

```c#
engine.Modules.Add("user", "export const name = 'John';");

var ns = engine.Modules.Import("user");

var name = ns.Get("name").AsString();
```

Defining modules using the module builder, which allows you to export CLR classes and values from .NET:

```c#
// Create the module 'lib' with the class MyClass and the variable version
engine.Modules.Add("lib", builder => builder
    .ExportType<MyClass>()
    .ExportValue("version", 15)
);

// Create a user-defined module and do something with 'lib'
engine.Modules.Add("custom", @"
    import { MyClass, version } from 'lib';
    const x = new MyClass();
    export const result = x.doSomething();
");

// Import the user-defined module; this will execute the import chain
var ns = engine.Modules.Import("custom");

// The result contains "live" bindings to the module
var id = ns.Get("result").AsInteger();
```

Note that you don't need to `EnableModules` if you only use modules created using `Engine.Modules.Add`.

If you serve the same modules from a pool of engines, see **Sharing a module graph across pooled engines**
under [Embedding performance](#embedding-performance): a loader that caches prepared modules keeps every
engine but the first from parsing them again.

### How a module is named

Every module has a location — the string it knows itself by, `Module.Location` — and for a module a loader
produced, that string is `ModuleFactory.LocationOf(resolved)`: the `LocalPath` of an absolute `file:` uri, and
otherwise `ResolvedSpecifier.Key`, exactly as your `Resolve` wrote it. It is never null.

It is worth getting right because four things read it:

- your own `ModuleLoader.Resolve`, as `referencingModuleLocation`, whenever that module imports something
  relative;
- `error.stack`, and any `SyntaxError` a malformed module raises, through `SourceLocation.SourceFile`;
- the debugger, which keys breakpoints on it — `new BreakPoint(location, line, column)`;
- `import.meta.url`, if you report it. Jint leaves `import.meta` to the host, so it is your
  `Host.GetImportMetaProperties` override that puts the location there.

So a loader serving modules over a transport should key them by the whole url rather than by a path. A module
that knows itself as `/lib/entry.js` has no origin left for its own `./dep.js` to resolve against; one that
knows itself as `http://localhost/lib/entry.js` resolves it the way a browser would. The key is used verbatim
rather than `Uri.AbsoluteUri`, which canonicalizes — strips a default port, lowercases the host, collapses
dot segments, percent-encodes — and whose .NET Framework and .NET Core parsers disagree on parts of that, so
a canonicalized name would differ per target framework and could drift from the key the module map is cached
under. Loading from disk is unaffected: a `file:` uri keeps its path, which is what `DefaultModuleLoader`
resolves against a filesystem base path.

One consequence to weigh if the url carries anything sensitive. This string reaches script through
`new Error().stack`, so a loader keying modules by `https://svc:s3cr3t@internal.corp/lib/a.js?apikey=...`
hands untrusted script the credential and the api key. A browser's `import.meta.url` carries the query too,
so this follows from naming a module by its url at all; keep secrets out of the key, or out of the url.

If you name modules yourself — preparing each one once and sharing the `Prepared<AstModule>` across pooled
engines, per **Sharing a module graph across pooled engines** — call `ModuleFactory.LocationOf` for the name
rather than deriving it by hand. A name that differs from the engine's own answer breaks relative-import
resolution with nothing to point at.

### Loading modules asynchronously

`IModuleLoader.LoadModule` must return a parsed module immediately, so a loader that fetches module source over I/O — HTTP, a dev server, an asset pipeline — would have to block the calling thread. Implement `IAsyncModuleLoader` instead, or derive from the `AsyncModuleLoader` template, and no thread is held while the fetch is in flight:

```c#
internal sealed class HttpModuleLoader : AsyncModuleLoader
{
    private readonly HttpClient _client = new() { BaseAddress = new Uri("http://localhost:5173/") };

    // Resolution stays synchronous — only fetching an unseen module is allowed to take time
    public override ResolvedSpecifier Resolve(string? referencingModuleLocation, ModuleRequest moduleRequest)
    {
        var baseUri = new Uri(referencingModuleLocation ?? _client.BaseAddress!.ToString());
        var uri = new Uri(baseUri, moduleRequest.Specifier);
        return new ResolvedSpecifier(moduleRequest, uri.AbsoluteUri, uri, SpecifierType.RelativeOrAbsolute);
    }

    protected override Task<string> LoadModuleContentsAsync(Engine engine, ResolvedSpecifier resolved, CancellationToken cancellationToken)
        => _client.GetStringAsync(resolved.Uri);
}

var engine = new Engine(options => options.EnableModules(new HttpModuleLoader()));

var ns = await engine.Modules.ImportAsync("./main.js");
```

Static imports inside an asynchronously loaded module are fetched the same way, transitively, before anything is linked; a module wanted by several importers is fetched once. A loader failure — a faulted task, or `ModuleLoadCompletion.SetError` — becomes a rejected promise rather than an exception on the calling thread, and a dynamic `import()` in script keeps working with nothing blocked:

```c#
// Returns immediately; the promise settles on a later turn of the event loop
engine.Execute("import('./late.js').then(ns => log(ns.value));");
```

For full control over when and where the load finishes, implement `IAsyncModuleLoader` directly and settle the `ModuleLoadCompletion` whenever the content arrives, from any thread:

```c#
public void LoadModuleAsync(Engine engine, ResolvedSpecifier resolved, ModuleLoadCompletion completion)
{
    // e.g. a Unity coroutine, a callback-based transport, a worker queue
    StartCoroutine(Fetch(resolved.Uri, onSuccess: completion.SetSource, onError: completion.SetError));
}
```

The engine is single-threaded, and settling the completion does not change that: the outcome is queued and applied when the engine is next given a turn. On a thread the engine must not block — a game loop, a UI thread — drive the import from your own loop instead of awaiting it:

```c#
// once
var import = engine.Modules.StartImport("./main.js");

// every frame
engine.Advanced.ProcessTasks();
if (import.IsCompleted)
{
    var ns = import.GetResult();   // throws PromiseRejectedException if the load or evaluation failed
}
```

The synchronous `Engine.Modules.Import` still works with an async loader, but the calling thread is what drives the event loop while the loads are in flight — so it deadlocks if the loader's own completions need that same thread. Prefer `ImportAsync` or `StartImport` there. Existing synchronous `IModuleLoader` implementations are unaffected; async loading is opt-in.

A completion settled *before* `LoadModuleAsync` returns — a cache hit, source already in hand — is the exception to all of the above: the load finishes on the calling stack, no event loop involved, so a graph made entirely of such answers keeps the blocking `Import` fully synchronous, exactly as if a synchronous `IModuleLoader` had served it. `AsyncModuleLoader` does this automatically whenever `LoadModuleContentsAsync` returns an already-completed task.

## Asynchronous Execution

Jint supports non-blocking execution of JavaScript that involves `async`/`await` and Promises. This is important in ASP.NET Core and other environments where blocking a thread while waiting for I/O can cause thread-pool exhaustion.

### EvaluateAsync / ExecuteAsync / InvokeAsync

Use `EvaluateAsync` when you want to evaluate JavaScript code that may return a Promise (e.g., an `async` function call). The method awaits Promise settlement without blocking any thread — the calling thread is released back to the pool while I/O is in flight:

```c#
var engine = new Engine();

// Expose an async .NET method to JavaScript
engine.SetValue("fetchData", new Func<string, Task<string>>(async url =>
{
    using var client = new HttpClient();
    return await client.GetStringAsync(url);
}));

// EvaluateAsync properly awaits the Promise returned by the async IIFE
var result = await engine.EvaluateAsync("""
    (async () => {
        const data = await fetchData('https://example.com/api');
        return data;
    })()
    """);

Console.WriteLine(result.AsString());
```

`ExecuteAsync` and `InvokeAsync` follow the same pattern:

```c#
// Execute a script that may produce a Promise and await its completion
await engine.ExecuteAsync("async function init() { ... } init()");

// Invoke a named async function and await its result
var value = await engine.InvokeAsync("myAsyncFunction", arg1, arg2);
```

By default, async execution respects `Options.Constraints.PromiseTimeout`. You can also pass a `CancellationToken`:

```c#
using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(10));
var result = await engine.EvaluateAsync("(async () => await fetchData(url))()", cancellationToken: cts.Token);
```

### UnwrapIfPromiseAsync

When you already hold a `JsValue` that may be a Promise — for example returned from `engine.Invoke(...)`, `value.Call(...)`, or a property access — use `UnwrapIfPromiseAsync` to await it without blocking:

```c#
// Obtain a JsValue that may be a Promise
var jsValue = engine.Invoke("computeAsync", someArg);

// Await it asynchronously (non-blocking)
var result = await jsValue.UnwrapIfPromiseAsync();

// With cancellation support
using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(5));
var result = await jsValue.UnwrapIfPromiseAsync(cts.Token);
```

If `jsValue` is not a Promise it is returned immediately. If it is a rejected Promise a `PromiseRejectedException` is thrown.

The synchronous `UnwrapIfPromise` is still available for scenarios where blocking is acceptable (e.g., CPU-bound scripts with no I/O), but `UnwrapIfPromiseAsync` should be preferred in any `async` call chain.

### Task/ValueTask to Promise Interop (Experimental)

When the `TaskInterop` experimental feature is enabled, .NET `Task` and `ValueTask` return values are automatically converted to JavaScript Promises. This allows JavaScript code to `await` or `.then()` the results of .NET async methods without any manual wrapping:

```c#
var engine = new Engine(options =>
{
    options.ExperimentalFeatures = ExperimentalFeature.TaskInterop;
});

engine.SetValue("fetchData", new Func<string, Task<string>>(async url =>
{
    using var client = new HttpClient();
    return await client.GetStringAsync(url);
}));

// .NET Task is automatically converted to a JavaScript Promise
var result = engine.Evaluate("fetchData('https://example.com/api').then(data => data)");
result = result.UnwrapIfPromise();
```

Without `TaskInterop`, .NET Tasks passed to JavaScript are exposed as opaque CLR objects. With it enabled, they become native Promises that support `await`, `.then()`, and `.catch()`.

You can configure the timeout for promise resolution via `Options.Constraints.PromiseTimeout`:

```c#
var engine = new Engine(options =>
{
    options.ExperimentalFeatures = ExperimentalFeature.TaskInterop;
    options.Constraints.PromiseTimeout = TimeSpan.FromSeconds(10);
});
```

## .NET Interoperability

- Manipulate CLR objects from JavaScript, including:
  - Single values
  - Objects
    - Properties
    - Methods
  - Delegates
  - Anonymous objects
- Convert JavaScript values to CLR objects
  - Primitive values
  - Object -> expando objects (`IDictionary<string, object>` and dynamic)
  - Array -> object[]
  - Date -> DateTime
  - number -> double
  - string -> string
  - boolean -> bool
  - RegExp -> Regex
  - Function -> Delegate
- Extensions methods

## Error handling

### A CLR exception thrown by host code

By default an exception thrown by host code — a delegate you registered, a reflected member, a proxy trap —
is **not** converted into anything. It bubbles straight out of `Execute`/`Evaluate`/`Invoke` to you, with its
message, .NET stack trace and inner exceptions untouched, and the script gets no chance to catch it:

```c#
var engine = new Engine();
engine.SetValue("parse", new Action<string>(s => new XmlDocument().LoadXml(s)));

// throws System.Xml.XmlException, with its own stack trace
engine.Evaluate("parse('<not xml')");
```

`CatchClrExceptions` changes that: the exception becomes a JavaScript `Error` carrying its message, which the
script can `try`/`catch` like any other. The predicate overload decides per exception, so you can let the
script handle what it should handle and keep the rest fatal.

```c#
var engine = new Engine(options => options.CatchClrExceptions(e => e is not OperationCanceledException));
```

### Getting the original exception back

Once an exception has been turned into a JavaScript error, the error is what travels — so when the script does
not catch it and it reaches you as a `JavaScriptException`, the message alone is rarely enough to diagnose
anything. `JintException.TryGetClrException` gives you the exception itself:

```c#
try
{
    engine.Evaluate(script);
}
catch (JavaScriptException e) when (JintException.TryGetClrException(e, out var clrException))
{
    logger.LogError(clrException, "host call failed while running {Script}", name);
}
```

It survives nested frames, a script catching and rethrowing the same error, module evaluation and a rejected
promise (`PromiseRejectedException`), and it follows the standard `cause` chain, so a script that rewraps with
`throw new Error(msg, { cause: err })` keeps it too. A script that throws something unrelated instead keeps
nothing, which is correct — it discarded the original.

The exception is host-only. It is CLR state on the error object rather than a JavaScript property, so a script
can neither read it nor strip it, and it does not appear in `Object.getOwnPropertyNames`, `Reflect.ownKeys` or
`JSON.stringify`. Note that the error object holds the exception, and everything the exception's object graph
reaches, for as long as the script keeps the error reachable.

If you would rather your logging pipeline find it without asking, `ChainClrExceptions` also hangs it in the
`InnerException` chain, so `ToString()` and any chain-walking logger render your own frames alongside the
JavaScript ones. It is off by default because it puts host stack traces into whatever consumes that string —
treat it the way an ASP.NET application treats developer exception details.

```c#
var engine = new Engine(options => options
    .CatchClrExceptions()
    .ChainClrExceptions());
```

Two related accessors work the same way: `JintException.TryGetJavaScriptLocation` and
`TryGetJavaScriptCallStack` give the JavaScript position for both `JavaScriptException` and a bubbled CLR
exception, and `TryGetClrType`/`TryGetClrMemberName` report the type and member behind a failed interop
resolution. To shape what the *script* sees — rewrite the message, attach an error code —
use `DecorateClrExceptionErrors`.

### Raising an error from host code

To fail a host function in a way the script can catch, throw a `JavaScriptException`. The overload taking a
CLR exception records it for `TryGetClrException`, so the script sees an ordinary `Error` while you keep the
original:

```c#
engine.SetValue("parse", new Action<string>(s =>
{
    try
    {
        new XmlDocument().LoadXml(s);
    }
    catch (XmlException e)
    {
        throw new JavaScriptException(engine.Intrinsics.Error, "XML parsing failed", e);
    }
}));
```

Do not throw the exception projected into the script instead
(`new JavaScriptException(JsValue.FromObject(engine, e))`). That value is not an `Error` — it has no `stack`
and fails `instanceof Error` — and it hands the running script the exception's members, including its .NET
stack trace and inner exceptions.

## Security

Jint is an in-process interpreter, not an operating-system security boundary. Running
untrusted scripts safely requires explicit limits, a minimal host capability surface, fresh
engines across trust domains, and process-level isolation. See the
[threat model](.github/THREAT_MODEL.md) for the supported boundaries, known limitations, and
a hardened deployment baseline.

- Define memory limits, to prevent allocations from depleting the memory.
- Enable/disable usage of BCL to prevent scripts from invoking .NET code.
- Limit number of statements to prevent infinite loops.
- Limit depth of calls to prevent deep recursion calls.
- Define a timeout, to prevent scripts from taking too long to finish.
- Turn an unbounded recursion into a catchable error rather than a stack overflow that ends the process
  (see [Surviving an unbounded recursion](#surviving-an-unbounded-recursion); off by default).

## Branches and releases

- The recommended branch is __main__, any PR should target this branch
- The __main__ branch is automatically built and published on [MyGet](https://www.myget.org/feed/Packages/jint). Add this feed to your NuGet sources to use it: https://www.myget.org/F/jint/api/v3/index.json
- The __main__ branch is occasionally published on [NuGet](https://www.nuget.org/packages/jint)

---

## File: Jint.Benchmark/README.md

# Engine comparison benchmarks

This project benchmarks Jint against the other JavaScript engines available to .NET applications:
the managed engines ([NiL.JS](https://github.com/nilproject/NiL.JS),
[Okojo](https://github.com/akeit0/okojo) and [YantraJS](https://github.com/yantrajs/yantra)) and
[ClearScript](https://github.com/ClearFoundry/ClearScript) — Microsoft-originated, now
ClearFoundry-maintained bindings to Google's native V8 engine (the JIT inside Chrome and Node.js) —
across a set of representative scripts.

## How each engine executes

The engines reach the result in different ways, which shapes the numbers below:

* **Jint** — tree-walking interpreter over a prepared AST.
* **NiL.JS** — interpreter (with an optimizing pass over its syntax tree).
* **Okojo** — interpreter that compiles the script to bytecode and runs it on a virtual machine.
* **YantraJS** — compiler: it emits .NET IL, which the CLR then JIT-compiles to native code.
* **ClearScript (V8)** — native V8 behind a managed ↔ native interop bridge: a multi-tier
  optimizing JIT running outside the CLR, with every host interaction crossing the native boundary.

The structural consequences shape the whole table. Only the two compilers (YantraJS and V8) run
ahead on long, tight numeric/call loops, where compiled code approaches native speed. The
interpreters own the other end of the trade: engine start-up and small scripts, where even a
context created from a pre-warmed V8 isolate costs ~375 µs for work Jint completes in about a
microsecond. And pure-JS compute is only half of an embedding story — the other half is the
script ↔ host boundary, measured separately in the
[interop section](#script--host-interop) below, where the price of V8's native boundary inverts
the picture.

## The scripts

One variant per workload, 12 scripts in total. Where the suite previously carried both a classic
ES5 script and an ES2015+ `-modern` rewrite of it, only the modern variant is kept — that is how
JavaScript is written today, and the duplicated rows ranked the engines nearly identically while
doubling the wall-clock time of a full run. (The classic scripts remain in `Scripts/` and are still
used by the Jint-only benchmarks.)

## Running the benchmarks

Run from **this** directory (the scripts are loaded relative to the working directory):

```
dotnet run -c Release -- --allCategories EngineComparison
```

Notes:

* The `--` separator is required so the arguments are forwarded to BenchmarkDotNet instead of being
  consumed by `dotnet run`.
* `--allCategories EngineComparison` runs both the script suite and the interop suite; use
  `--allCategories EngineComparisonInterop` for the interop suite alone, or
  `--filter "*EngineComparisonBenchmark*"` for the script suite alone.
* Results are written to `BenchmarkDotNet.Artifacts/results/` — the
  `*-report-github.md` file is the table reproduced below.
* To re-measure a single engine (e.g. after a package bump) without disturbing the rest of the
  table, filter to its lane, for example `--filter "*EngineComparisonBenchmark.Okojo*"`.
* The benchmark config widens the parameter column (`MaxParameterColumnWidth = 40`) so the full
  script names are printed instead of BenchmarkDotNet's default truncation (e.g.
  `dromaeo-object-string-modern` rather than `droma(...)odern [28]`).

## How to read the table

* All engines are run in **global strict mode** — YantraJS is strict-only, and Okojo and
  ClearScript have no engine-level strict switch, so their source carries a leading `"use strict"`
  directive. Strict mode improves performance across the board.
* Every operation uses a **fresh engine** — the embedding pattern where executions must not leak
  state into each other.
* Three engines have a **cached-artifact lane** next to the re-parse lane, and the pairs mean the
  same thing: `Jint_ParsedScript` reuses a `Prepared<Script>` produced once by
  `Engine.PrepareScript`; `Okojo_Prepared` reuses a parsed program (Okojo's realm-independent
  artifact) and re-compiles the bytecode against each run's fresh realm; `ClearScript_Compiled`
  reuses a `V8Script` compiled once by a shared `V8Runtime` and runs it in a fresh script engine (a
  fresh V8 context) created from that runtime. The gap to the re-parse lane is parsing/compilation
  cost — **in production you should cache the prepared artifact**, which is what these lanes
  represent.
* The plain `ClearScript` lane creates a full V8 isolate + context per operation — the honest cost
  when each request gets a fully isolated engine, and the reason its short-script rows start around
  a millisecond. `ClearScript_Compiled` shares one isolate (and its warmed JIT state) across
  operations while still using a fresh context per operation — ClearScript's recommended production
  path.
* **`Allocated` counts managed memory only.** ClearScript's working memory lives on V8's native
  heap, which the managed diagnoser cannot see — the few dozen KB in its rows are interop-bridge
  overhead, not a memory-use figure comparable with the managed engines. Memory claims in this
  document therefore compare the managed engines with each other.
* V8 runs background threads (tiered JIT compilation, garbage collection). `Mean` is the wall-clock
  time the executing thread observes; total CPU consumed is higher than for the single-threaded
  managed engines, which matters on saturated servers.
* `Mean` is time per operation (lower is better); `Rank` groups results that are statistically
  tied. Every lane in both tables below comes from a single benchmark session on one machine, so
  ranks are BenchmarkDotNet's own — no rows are merged from separate runs. Cross-session
  comparisons of absolute numbers (including the V8 lanes) are unreliable; compare within a table.
* The `dromaeo-object-regexp-modern` row is the highest-variance in the table (for Jint it is
  dominated by .NET `Regex`); treat small gaps there — including ClearScript's fresh-engine lane
  appearing ahead of its compiled lane, and Jint's own two lanes sitting ~12% apart — as
  run-to-run noise. Jint's lead on that row is not one of those: the prepared lane is ~18 ms clear
  of the nearest V8 lane, more than five times its own standard deviation.

## At a glance

Using each engine's recommended production path (for Jint a cached prepared script,
`Jint_ParsedScript`; for ClearScript a precompiled `V8Script` on a shared runtime,
`ClearScript_Compiled`):

* **Jint owns everything start-up-shaped and eval-shaped; native V8 owns long compute.** Jint is
  the fastest engine outright on `minimal` (**1.1 µs vs V8's 380 µs, ~345×**), `evaluation-modern`
  (**~80×**), `linq-js` (**~6.7×**), `dromaeo-core-eval-modern` (**~5%** ahead of V8's compiled
  lane — eval defeats its compile cache) and `dromaeo-object-regexp-modern` (**1.25× ahead of V8's
  fresh-context lane and 1.46× ahead of its compiled lane**). That is five rows outright, out of
  twelve. No other managed engine takes a single row's top rank away from Jint or V8.
* **V8's wins are the tight-loop compute rows**: `dromaeo-string-base64-modern` (9.8×),
  `dromaeo-object-string-modern` (6.6×), `stopwatch-modern` (6.0×), `dromaeo-3d-cube-modern`
  (3.4×), `json-parse-modern` (2.2×) and narrow leads on `array-stress` (1.09×) and
  `dromaeo-object-array-modern` (1.08×) — the structural interpreter-vs-JIT gap. The two string
  rows carry the widest spread between Jint's own two lanes in this table (5% on base64, 10% on
  object-string, for lanes that differ only in whether the script was re-parsed), so read those
  two multipliers as approximate.
* **Jint is the fastest managed engine on 10 of 12 scripts** (the IL-compiling YantraJS leads
  `dromaeo-3d-cube-modern` and `stopwatch-modern`) and **the fastest interpreter on all 12**.
* **Jint allocates the least of the managed engines on 10 of 12 scripts** — Okojo is lower on
  `dromaeo-object-array-modern` (6,985 vs 9,122 KB) and NiL.JS on `minimal` (4.5 vs 9.9 KB).
  NiL.JS and YantraJS allocate one to two orders of magnitude more on the heavy rows, up to
  **~469×** more than Jint on `dromaeo-string-base64-modern` (763,918 vs 1,628 KB), which means
  far heavier GC pressure in real applications. (ClearScript's rows cannot be compared here — its
  memory lives on the V8 native heap, which the managed diagnoser does not see.)
* **Pure-JS compute is only half the story** — the [interop suite](#script--host-interop) below
  measures the script ↔ host boundary, where the picture inverts and Jint beats ClearScript on
  every row by 3.4×–11.2×.

### What changed since the 4.13.0 table

A profile-guided campaign (PRs [#2716](https://github.com/sebastienros/jint/pull/2716)–
[#2722](https://github.com/sebastienros/jint/pull/2722)) attacked the rows where V8 led, measured
with same-base A/B gates: string-receiver method calls are cached per call site
(`dromaeo-object-string-modern` −20%, `-base64-modern` −17%), JSON.parse interns property keys
(bestbuy-style payloads −22% and −32% allocation), chained `slice()` no longer materializes
intermediate views (−99.3% on that pattern), interop argument binding lost its per-call
reflection checks and boxing, ObjectWrapper members gained a per-callsite inline cache
(`interop-property-access` −25%), and CLR arrays gained identity caching plus an opt-in
`ArrayConversionMode.LiveView` mode (array traversal 2.5× faster, −75% allocation, without flags).

A second campaign round (PRs [#2725](https://github.com/sebastienros/jint/pull/2725),
[#2726](https://github.com/sebastienros/jint/pull/2726)) added bulk JSON string scanning plus an
exactly-rounded simple-number fast path (JsonBenchmark Parse −15–17%) and memoized closure-read
chain validation (`dromaeo-string-base64-modern` −6% at launchCount-5). A third candidate —
arity-specialized direct dispatch for built-in calls, eliminating the argument array — was built,
proven to engage on 4.3M of 4.3M eligible calls, and measured **flat**: Jint's builtin-call path
(pooled argument arrays + the cached-callee lane) is already at its cost floor, so the remaining
gap on the string rows is interpreter dispatch itself, not call ceremony. Measured-and-dropped is
recorded here so it isn't re-attempted.

The 4.14.0 release round shipped the two interop default flips — CLR arrays cross as live views
([#2728](https://github.com/sebastienros/jint/pull/2728)) and recently wrapped objects reuse their
wrappers ([#2734](https://github.com/sebastienros/jint/pull/2734)) — backed by cached array-like
wrapper factories with lazy length ([#2730](https://github.com/sebastienros/jint/pull/2730)),
boxing-free primitive element conversion ([#2731](https://github.com/sebastienros/jint/pull/2731),
extended to the `Array.prototype` iteration lane in
[#2735](https://github.com/sebastienros/jint/pull/2735)), a compiled-invoker fast lane for
single-candidate interop calls ([#2733](https://github.com/sebastienros/jint/pull/2733)) and
JSON.parse value interning plus span-based number parsing
([#2732](https://github.com/sebastienros/jint/pull/2732)). The visible movement in this table:
`interop-collection-traversal` **15,597 → 1,433 µs (10.9×, −99% allocation)** without any script
changes, every other interop row −8–16% with −17–76% allocation, `json-parse-modern` −6% time and
−23% allocation, and `stopwatch-modern` −6%. A pre-release review wave
([#2735](https://github.com/sebastienros/jint/pull/2735)–[#2740](https://github.com/sebastienros/jint/pull/2740))
hardened the new defaults (declared-type contracts, JS-array `in`/enumeration/out-of-range
semantics, constraint-gate balance) with no measurable cost; one further candidate — carrying the
interned JSON key hash into member adds — measured flat and was dropped.

Since 4.14.0, a further interop round cached the compiled method invoker process-wide instead of
per-engine ([#2743](https://github.com/sebastienros/jint/pull/2743)), compiled CLR property and
field access instead of reflecting on every hit ([#2744](https://github.com/sebastienros/jint/pull/2744),
which also more than halved `interop-property-access` allocation, 798 → 329 KB), trimmed the method
fast lane's per-call overhead ([#2745](https://github.com/sebastienros/jint/pull/2745)), and
memoized the converted value of a stable reference-typed property so a host array read in a loop
skips re-conversion ([#2756](https://github.com/sebastienros/jint/pull/2756)). The visible movement
in the interop table: `interop-collection-traversal` and `interop-string-passing` now rank first
(collection −8% from the memo alone, ahead of NiL.JS), and method calls closed to within ~4% of
NiL.JS while still allocating 7× less.

### What changed for 4.15.0

The 4.15.0 round shipped a string and regexp allocation wave — vectorized special-casing and
search pre-scans ([#2775](https://github.com/sebastienros/jint/pull/2775),
[#2776](https://github.com/sebastienros/jint/pull/2776)), `toWellFormed` no longer rebuilding
already-well-formed strings ([#2778](https://github.com/sebastienros/jint/pull/2778)), dense fast
paths for the callback-free array methods ([#2779](https://github.com/sebastienros/jint/pull/2779),
[#2780](https://github.com/sebastienros/jint/pull/2780)) and the string-concat plus RegExp fixes
aimed at this suite's regexp row ([#2781](https://github.com/sebastienros/jint/pull/2781), with
follow-up concat correctness in [#2811](https://github.com/sebastienros/jint/pull/2811) and
[#2812](https://github.com/sebastienros/jint/pull/2812)) — a fast-call lane for built-in calls
with declared per-argument leaf guards
([#2783](https://github.com/sebastienros/jint/pull/2783),
[#2828](https://github.com/sebastienros/jint/pull/2828),
[#2844](https://github.com/sebastienros/jint/pull/2844)), span- and UTF-8-based JSON parsing
([#2832](https://github.com/sebastienros/jint/pull/2832)), and an interop round that compiles CLR
member access for keyed writes, indexers and statics
([#2839](https://github.com/sebastienros/jint/pull/2839)), shares resolved members process-wide
across engines ([#2798](https://github.com/sebastienros/jint/pull/2798)) and stops re-reflecting
on every host delegate call ([#2799](https://github.com/sebastienros/jint/pull/2799)).

The visible movement in these tables: `dromaeo-object-regexp-modern`
**123,563 → 71,625 µs (−42%) with −47% allocation** (157,850 → 82,980 KB), which takes the row
from rank 3 to rank 1 — ahead of both V8 lanes, and the first time Jint leads it;
`dromaeo-object-string-modern` **−21%**; `dromaeo-string-base64-modern` **−13%** on the prepared
lane (the re-parse lane's −30% is partly the previous session's high reading — the two Jint lanes
now agree to within 1%); `array-stress` −5%, back to a rank-1 tie with V8's compiled lane;
`json-parse-modern` −1% time with −4% allocation. On the interop side `interop-property-access` is
−11% and `interop-method-calls` −4%, while `interop-collection-traversal` moved the other way
(+5%) and NiL.JS retook that row by ~4%.

### What changed for 4.16.0

The headline of the 4.16.0 round is **proper tail calls for strict functions**
([#2975](https://github.com/sebastienros/jint/pull/2975)): tail-position analysis plus a trampoline
that dispatches an interpreted tail call without growing the execution-context or call stacks,
with cleanup, constructor, callback, debugger and recursion-limit semantics preserved. In Jint's
own script benchmarks — not this comparison suite — the `controlflow-recursive` row measured
**−15.6% time and −40.4% allocation** against 4.15.3. Here it lands wherever a script recurses in
tail position rather than on any single row.

The fast-call lane — built-in calls that skip the pooled argument array and, where every route to
user code is closed off by a checkable guard, the call frame as well — grew again:
`parseInt`/`parseFloat` became one realm intrinsic each and took the frameless lane
([#2968](https://github.com/sebastienros/jint/pull/2968)); the cheapest `Number` type tests and six
`String.prototype` search methods followed under declared per-argument guards
([#2980](https://github.com/sebastienros/jint/pull/2980)); and `Map`/`Set` lookups became frameless
once each instance carried a type bit the guard could check
([#2984](https://github.com/sebastienros/jint/pull/2984)). On the interop side a wrapped dictionary
now answers existence questions — `in`, `hasOwnProperty`, `for..in`, `Object.keys`, spread,
`JSON.stringify` — from the target's compiled `ContainsKey` instead of converting the value and
building a descriptor only to discard both
([#2969](https://github.com/sebastienros/jint/pull/2969)); no script in the interop suite
enumerates a host dictionary, so that one does not surface in the table below.

One correctness fix went the other way, and its cost is disclosed rather than absorbed quietly:
`Array.prototype.join` (and `toString`, which is defined as a call to it) now re-reads a hole
through the array instead of answering `undefined` from its snapshot, because a `toString` side
effect on an earlier element can add an index property to the prototype that every later element
has to see ([#3003](https://github.com/sebastienros/jint/pull/3003)). The packed path is untouched;
a hole-heavy join costs **+3.4%**.

Against the 4.15.0 tables: the two sessions ran on different runtime and OS builds (.NET 10.0.10 →
10.0.11) with a YantraJS bump in between, so no row-for-row delta is claimed here — the comparison
below is directional only. The rank structure is the one 4.15.0 published, with one change of lead
in each table, and they point in opposite directions: `array-stress` slips out of its rank-1 tie,
leaving V8's compiled lane 1.09× ahead, while `interop-collection-traversal` puts Jint back into a
rank-1 tie with NiL.JS. Every other row is led by the engine that led it before, and
`dromaeo-object-regexp-modern` stays Jint's, ~18 ms clear of the nearest V8 lane.

## Script ↔ host interop

Embedding a JavaScript engine is rarely about pure computation — scripts exist to drive the host
application, and in interop-heavy systems the script ↔ host boundary dominates. This is also where
the engines differ structurally: the managed engines dispatch host calls in-process, while every
ClearScript host interaction crosses the managed ↔ native V8 boundary and marshals its arguments
across it.

`EngineComparisonInteropBenchmark` (run with `--allCategories EngineComparisonInterop`) drives
four byte-identical scripts against each engine: a host method-call loop, a host property
read/write loop, strings crossing the boundary, and traversal of a host `int[]`. Details that
keep the comparison fair:

* Host members are lowercase (`host.add`, `host.value`, …) because YantraJS camel-cases CLR
  member names while the other engines surface them verbatim — already-lowercase names are the
  fixed point of both conventions, so every engine runs the same source.
* Each script validates its final aggregate and throws on a mismatch, so an engine that silently
  mis-marshals (undefined, NaN) fails loudly instead of posting a fantasy time.
* `ClearScript` binds the host object with plain `AddHostObject` (reflection-based, like the
  managed engines); `ClearScript_FastProxy` uses ClearScript 7.5's FastProxy API — explicit
  member registration with zero-allocation marshaling for fundamental types — its recommended
  path for hot host objects.
* Okojo is absent: 0.1.2-preview.1 provides no public way to enable CLR access.
* As above, `Allocated` is meaningful for the managed engines but only counts bridge overhead
  for the two ClearScript lanes.

What the numbers show:

* **The managed engines win every interop row.** Crossing the native boundary costs plain
  ClearScript **8.6×–11.2×** against Jint on every row — the mirror image of the pure-compute
  table, and the half of the story that matters most in chatty embedding scenarios.
* **FastProxy narrows the gap but does not close it**: still **3.4×–7.0×** behind Jint, and it
  trades away convenience — every member is hand-registered instead of reflected. Its
  zero-allocation claim is real, though: 13 KB managed allocation on the method-call row where
  reflective ClearScript burns 12,753 KB.
* **Jint leads string passing outright, is tied for the lead on collection traversal, and
  allocates the least of the managed engines on all four rows.** It is rank 1 on
  `interop-string-passing` (522.4 µs, ~10% clear of YantraJS) and rank 1 alongside NiL.JS on
  `interop-collection-traversal` (1,251.0 vs 1,242.7 µs — 0.7% apart, a statistical tie that
  BenchmarkDotNet ranks equal). It is rank 2 on `interop-method-calls` (NiL.JS ahead, 1,172.2 vs
  1,440.0 µs, Jint +23%) and on `interop-property-access` (YantraJS ahead, 1,451.9 vs 1,489.8 µs,
  Jint +2.6%). Allocation is Jint's on every row: 3.9×–12.4× less than the row's nearest managed
  competitor. (Three ClearScript_FastProxy rows show smaller KB figures, but those count
  interop-bridge overhead only — V8's working memory is on its native heap.)
* **Collection traversal — last of all engines at 4.13.0 — stays transformed at
  15,597 → 1,251 µs (12.5×, −99% allocation) with no script changes**: the 4.14.0
  `ArrayConversionMode.LiveView` default exposes the host array as a live view instead of
  re-copying it on every read, and a per-descriptor value memo
  ([#2756](https://github.com/sebastienros/jint/pull/2756)) skips re-converting the array on every
  read. NiL.JS took the row back by ~4% in the previous session; here the two are level (0.7%
  apart, both rank 1) while NiL.JS allocates 12× more. Either way the old hoist-into-a-local
  workaround is no longer needed.

| Method                | FileName                     | Mean        | StdDev   | Rank | Allocated   |
|---------------------- |----------------------------- |------------:|---------:|-----:|------------:|
| NilJS                 | interop-collection-traversal |  1,242.7 μs |  3.19 μs |    1 |  4088.14 KB |
| Jint                  | interop-collection-traversal |  1,251.0 μs |  1.78 μs |    1 |   330.97 KB |
| YantraJS              | interop-collection-traversal |  3,685.3 μs | 13.86 μs |    2 |  5395.96 KB |
| ClearScript_FastProxy | interop-collection-traversal |  8,779.5 μs | 18.91 μs |    3 |  1185.72 KB |
| ClearScript           | interop-collection-traversal | 11,691.8 μs | 27.62 μs |    4 |  5016.24 KB |
|                       |                              |             |          |      |             |
| NilJS                 | interop-method-calls         |  1,172.2 μs |  3.76 μs |    1 |  2437.94 KB |
| Jint                  | interop-method-calls         |  1,440.0 μs |  2.86 μs |    2 |   328.37 KB |
| YantraJS              | interop-method-calls         |  2,102.4 μs |  8.30 μs |    3 |  3355.13 KB |
| ClearScript_FastProxy | interop-method-calls         |  5,457.7 μs | 15.37 μs |    4 |    13.01 KB |
| ClearScript           | interop-method-calls         | 16,108.5 μs | 57.35 μs |    5 | 12752.52 KB |
|                       |                              |             |          |      |             |
| YantraJS              | interop-property-access      |  1,451.9 μs |  3.45 μs |    1 |  1870.68 KB |
| Jint                  | interop-property-access      |  1,489.8 μs |  3.12 μs |    2 |    329.3 KB |
| NilJS                 | interop-property-access      |  1,702.0 μs |  5.10 μs |    3 |  4391.52 KB |
| ClearScript_FastProxy | interop-property-access      |  5,111.8 μs |  9.73 μs |    4 |    12.66 KB |
| ClearScript           | interop-property-access      | 12,875.7 μs | 20.43 μs |    5 | 10561.78 KB |
|                       |                              |             |          |      |             |
| Jint                  | interop-string-passing       |    522.4 μs |  0.96 μs |    1 |   304.08 KB |
| YantraJS              | interop-string-passing       |    577.5 μs |  3.25 μs |    2 |  1714.38 KB |
| NilJS                 | interop-string-passing       |    769.8 μs |  1.45 μs |    3 |  1179.64 KB |
| ClearScript_FastProxy | interop-string-passing       |  2,961.1 μs |  9.59 μs |    4 |   247.15 KB |
| ClearScript           | interop-string-passing       |  5,263.2 μs | 19.95 μs |    5 |  2470.18 KB |

## Engine versions

* Jint 4.16.0
* NiL.JS 2.6.1722
* Okojo 0.1.2-preview.1
* YantraJS.Core 1.2.422
* Microsoft.ClearScript.V8 7.5.1

Both tables come from one benchmark session on the same machine and .NET runtime (all lanes,
including ClearScript, measured together): 116 benchmarks — 96 script rows (8 lanes × 12 scripts)
and 20 interop rows (5 lanes × 4 scripts) — default job, otherwise idle machine. ClearScript's V8
lanes land within ~3% of the previous (2026-07-28) session on the identical package, so those rows
are broadly comparable across the two — but the ~30% swing those same lanes showed between the
4.14.0 and 2026-07-24 sessions is the standing reminder that the native-JIT rows carry more
session-to-session variance than the managed engines, and that absolute numbers should be compared
within a table rather than across sessions. Two things moved under the whole table between the two
sessions besides Jint itself: YantraJS 1.2.419 → 1.2.422, and the host runtime .NET 10.0.10 →
10.0.11 (SDK 10.0.302 → 10.0.400) on a newer Windows build. Last updated 2026-08-13 (4.16.0
release candidate `7b56c8341`).

```

BenchmarkDotNet v0.15.8, Windows 11 (10.0.26200.9168/25H2/2025Update/HudsonValley2)
AMD Ryzen 9 5950X 3.40GHz, 1 CPU, 32 logical and 16 physical cores
.NET SDK 10.0.400
  [Host]     : .NET 10.0.11 (10.0.11, 10.0.1126.37416), X64 RyuJIT x86-64-v3
  DefaultJob : .NET 10.0.11 (10.0.11, 10.0.1126.37416), X64 RyuJIT x86-64-v3

```
| Method               | FileName                     | Mean             | StdDev         | Rank | Allocated     |
|--------------------- |----------------------------- |-----------------:|---------------:|-----:|--------------:|
| ClearScript_Compiled | array-stress                 |     2,035.717 μs |      7.6419 μs |    1 |        8.1 KB |
| Jint                 | array-stress                 |     2,209.995 μs |      3.9495 μs |    2 |    1091.93 KB |
| Jint_ParsedScript    | array-stress                 |     2,212.058 μs |      5.5029 μs |    2 |     1063.2 KB |
| YantraJS             | array-stress                 |     2,815.214 μs |     26.4164 μs |    3 |   17093.93 KB |
| ClearScript          | array-stress                 |     3,295.998 μs |      9.5510 μs |    4 |      16.06 KB |
| NilJS                | array-stress                 |     4,845.159 μs |      6.6924 μs |    5 |    4521.19 KB |
| Okojo                | array-stress                 |     5,546.333 μs |     17.9347 μs |    6 |    2697.82 KB |
| Okojo_Prepared       | array-stress                 |     5,546.651 μs |     25.6847 μs |    6 |    2682.11 KB |
|                      |                              |                  |                |      |               |
| ClearScript_Compiled | dromaeo-3d-cube-modern       |     1,361.995 μs |      4.2358 μs |    1 |       9.26 KB |
| YantraJS             | dromaeo-3d-cube-modern       |     2,299.281 μs |      5.9113 μs |    2 |    7436.04 KB |
| ClearScript          | dromaeo-3d-cube-modern       |     3,178.514 μs |     16.6576 μs |    3 |      14.49 KB |
| Jint_ParsedScript    | dromaeo-3d-cube-modern       |     4,607.760 μs |      8.5718 μs |    4 |    1374.41 KB |
| Jint                 | dromaeo-3d-cube-modern       |     4,988.145 μs |      6.7079 μs |    5 |    1679.78 KB |
| Okojo_Prepared       | dromaeo-3d-cube-modern       |     6,826.450 μs |    109.1199 μs |    6 |    2311.61 KB |
| NilJS                | dromaeo-3d-cube-modern       |     7,095.742 μs |      4.8978 μs |    7 |    5977.95 KB |
| Okojo                | dromaeo-3d-cube-modern       |     7,161.629 μs |     97.7917 μs |    7 |    2498.75 KB |
|                      |                              |                  |                |      |               |
| Jint_ParsedScript    | dromaeo-core-eval-modern     |       886.665 μs |      0.6373 μs |    1 |     346.77 KB |
| Jint                 | dromaeo-core-eval-modern     |       920.932 μs |      1.4350 μs |    2 |     366.23 KB |
| ClearScript_Compiled | dromaeo-core-eval-modern     |       933.105 μs |      3.4049 μs |    2 |       7.82 KB |
| NilJS                | dromaeo-core-eval-modern     |     1,382.077 μs |      1.4440 μs |    3 |    1575.94 KB |
| ClearScript          | dromaeo-core-eval-modern     |     2,052.775 μs |     12.2834 μs |    4 |       12.9 KB |
| YantraJS             | dromaeo-core-eval-modern     |     4,839.609 μs |     21.3171 μs |    5 |   35784.84 KB |
| Okojo                | dromaeo-core-eval-modern     |     5,766.205 μs |    282.7096 μs |    6 |    4628.16 KB |
| Okojo_Prepared       | dromaeo-core-eval-modern     |     6,731.548 μs |    166.2416 μs |    7 |    4613.12 KB |
|                      |                              |                  |                |      |               |
| ClearScript_Compiled | dromaeo-object-array-modern  |    13,511.360 μs |     28.1602 μs |    1 |      16.29 KB |
| Jint                 | dromaeo-object-array-modern  |    14,560.874 μs |    161.6323 μs |    2 |    9168.77 KB |
| Jint_ParsedScript    | dromaeo-object-array-modern  |    14,574.726 μs |    148.7198 μs |    2 |    9121.77 KB |
| ClearScript          | dromaeo-object-array-modern  |    15,233.491 μs |     42.0857 μs |    3 |     111.74 KB |
| YantraJS             | dromaeo-object-array-modern  |    26,468.928 μs |    449.6599 μs |    4 |  223683.36 KB |
| Okojo_Prepared       | dromaeo-object-array-modern  |    40,069.776 μs |     82.4893 μs |    5 |    6984.74 KB |
| Okojo                | dromaeo-object-array-modern  |    40,370.712 μs |     73.8563 μs |    5 |    7014.22 KB |
| NilJS                | dromaeo-object-array-modern  |    52,137.758 μs |     63.4400 μs |    6 |   17863.19 KB |
|                      |                              |                  |                |      |               |
| Jint_ParsedScript    | dromaeo-object-regexp-modern |    71,958.764 μs |  3,427.6529 μs |    1 |   82555.71 KB |
| Jint                 | dromaeo-object-regexp-modern |    80,412.888 μs |  6,125.1272 μs |    2 |   83913.27 KB |
| ClearScript          | dromaeo-object-regexp-modern |    90,178.237 μs |    286.2653 μs |    3 |      32.86 KB |
| ClearScript_Compiled | dromaeo-object-regexp-modern |   105,206.432 μs |  1,176.4466 μs |    4 |      15.71 KB |
| NilJS                | dromaeo-object-regexp-modern |   538,262.653 μs |  6,740.4339 μs |    5 |  767391.28 KB |
| YantraJS             | dromaeo-object-regexp-modern |   727,779.264 μs |  7,367.8313 μs |    6 |  826323.88 KB |
| Okojo_Prepared       | dromaeo-object-regexp-modern | 1,873,094.293 μs |  8,600.8802 μs |    7 | 1799271.88 KB |
| Okojo                | dromaeo-object-regexp-modern | 1,886,667.414 μs | 20,848.1909 μs |    7 | 1799460.78 KB |
|                      |                              |                  |                |      |               |
| ClearScript_Compiled | dromaeo-object-string-modern |     5,837.141 μs |     22.5034 μs |    1 |      15.64 KB |
| ClearScript          | dromaeo-object-string-modern |     8,561.271 μs |     27.2480 μs |    2 |      25.24 KB |
| Jint                 | dromaeo-object-string-modern |    35,062.101 μs |  1,535.6300 μs |    3 |   21529.67 KB |
| Jint_ParsedScript    | dromaeo-object-string-modern |    38,511.691 μs |  2,516.2942 μs |    4 |   21340.16 KB |
| Okojo_Prepared       | dromaeo-object-string-modern |    55,635.516 μs |  1,113.7534 μs |    5 |    33452.7 KB |
| Okojo                | dromaeo-object-string-modern |    55,910.038 μs |    646.7601 μs |    5 |    33511.2 KB |
| NilJS                | dromaeo-object-string-modern |   143,285.835 μs |  2,970.2749 μs |    6 | 1354957.51 KB |
| YantraJS             | dromaeo-object-string-modern |   176,114.896 μs |  6,047.6327 μs |    7 | 1648871.26 KB |
|                      |                              |                  |                |      |               |
| ClearScript_Compiled | dromaeo-string-base64-modern |     1,697.677 μs |      7.8604 μs |    1 |       8.89 KB |
| ClearScript          | dromaeo-string-base64-modern |     3,404.818 μs |     12.1244 μs |    2 |      15.38 KB |
| Jint_ParsedScript    | dromaeo-string-base64-modern |    16,717.857 μs |     31.9543 μs |    3 |    1628.09 KB |
| Jint                 | dromaeo-string-base64-modern |    17,639.956 μs |     21.7736 μs |    4 |    1728.46 KB |
| Okojo_Prepared       | dromaeo-string-base64-modern |    30,042.911 μs |    426.3164 μs |    5 |   43745.71 KB |
| Okojo                | dromaeo-string-base64-modern |    31,428.279 μs |    285.0574 μs |    6 |   43825.36 KB |
| NilJS                | dromaeo-string-base64-modern |    32,092.329 μs |    607.6797 μs |    6 |   31360.34 KB |
| YantraJS             | dromaeo-string-base64-modern |    35,415.762 μs |    762.1968 μs |    7 |  763917.73 KB |
|                      |                              |                  |                |      |               |
| Jint_ParsedScript    | evaluation-modern            |         4.651 μs |      0.0116 μs |    1 |      18.61 KB |
| Jint                 | evaluation-modern            |        14.038 μs |      0.0454 μs |    2 |      29.74 KB |
| NilJS                | evaluation-modern            |        25.992 μs |      0.0602 μs |    3 |      22.35 KB |
| YantraJS             | evaluation-modern            |       129.352 μs |      1.0605 μs |    4 |      703.4 KB |
| ClearScript_Compiled | evaluation-modern            |       374.891 μs |      1.1516 μs |    5 |       6.09 KB |
| ClearScript          | evaluation-modern            |     1,139.884 μs |      4.8187 μs |    6 |      10.97 KB |
| Okojo_Prepared       | evaluation-modern            |     1,437.314 μs |     49.8982 μs |    7 |    1283.54 KB |
| Okojo                | evaluation-modern            |     1,564.927 μs |     61.0150 μs |    8 |    1290.72 KB |
|                      |                              |                  |                |      |               |
| ClearScript_Compiled | json-parse-modern            |     7,465.707 μs |     18.3971 μs |    1 |       9.79 KB |
| ClearScript          | json-parse-modern            |     9,252.981 μs |     38.1479 μs |    2 |      17.14 KB |
| Jint_ParsedScript    | json-parse-modern            |    16,243.839 μs |    208.5431 μs |    3 |   11397.93 KB |
| Jint                 | json-parse-modern            |    16,680.470 μs |    224.1474 μs |    3 |   11434.71 KB |
| YantraJS             | json-parse-modern            |    24,030.128 μs |    202.9171 μs |    4 |   42849.84 KB |
| Okojo                | json-parse-modern            |    24,851.231 μs |     56.3649 μs |    5 |   27271.79 KB |
| Okojo_Prepared       | json-parse-modern            |    24,871.608 μs |     43.3566 μs |    5 |   27235.55 KB |
| NilJS                | json-parse-modern            |   126,595.546 μs |    275.3617 μs |    6 |   67095.19 KB |
|                      |                              |                  |                |      |               |
| Jint_ParsedScript    | linq-js                      |        68.403 μs |      0.2889 μs |    1 |     214.39 KB |
| YantraJS             | linq-js                      |       316.724 μs |      1.6240 μs |    2 |    1049.75 KB |
| ClearScript_Compiled | linq-js                      |       462.290 μs |      2.4241 μs |    3 |       6.21 KB |
| Jint                 | linq-js                      |     1,091.041 μs |      3.5935 μs |    4 |    1296.63 KB |
| ClearScript          | linq-js                      |     2,036.363 μs |      8.9904 μs |    5 |      10.96 KB |
| NilJS                | linq-js                      |     3,865.936 μs |      4.6159 μs |    6 |    2739.46 KB |
| Okojo_Prepared       | linq-js                      |     5,912.862 μs |    133.9733 μs |    7 |    4131.95 KB |
| Okojo                | linq-js                      |     8,574.856 μs |    337.6247 μs |    8 |    4928.88 KB |
|                      |                              |                  |                |      |               |
| Jint_ParsedScript    | minimal                      |         1.094 μs |      0.0051 μs |    1 |       9.92 KB |
| Jint                 | minimal                      |         2.095 μs |      0.0061 μs |    2 |      11.84 KB |
| NilJS                | minimal                      |         2.883 μs |      0.0080 μs |    3 |       4.51 KB |
| YantraJS             | minimal                      |       126.579 μs |      0.5990 μs |    4 |     697.62 KB |
| ClearScript_Compiled | minimal                      |       379.509 μs |      1.4249 μs |    5 |       6.12 KB |
| ClearScript          | minimal                      |     1,127.502 μs |      6.8833 μs |    6 |      10.97 KB |
| Okojo                | minimal                      |     1,136.618 μs |     79.5654 μs |    6 |    1249.24 KB |
| Okojo_Prepared       | minimal                      |     1,154.071 μs |     80.6357 μs |    6 |    1247.39 KB |
|                      |                              |                  |                |      |               |
| ClearScript_Compiled | stopwatch-modern             |    14,161.990 μs |     43.6106 μs |    1 |       9.01 KB |
| ClearScript          | stopwatch-modern             |    17,170.161 μs |     53.0071 μs |    2 |      22.67 KB |
| YantraJS             | stopwatch-modern             |    56,498.545 μs |    187.0381 μs |    3 |  233993.23 KB |
| Jint                 | stopwatch-modern             |    85,132.661 μs |    332.5876 μs |    4 |   12122.73 KB |
| Jint_ParsedScript    | stopwatch-modern             |    85,204.309 μs |    753.0055 μs |    4 |   12090.63 KB |
| Okojo                | stopwatch-modern             |   151,840.067 μs |    916.1697 μs |    5 |   21469.24 KB |
| Okojo_Prepared       | stopwatch-modern             |   155,504.922 μs |  2,858.1551 μs |    5 |   21445.98 KB |
| NilJS                | stopwatch-modern             |   209,122.986 μs |    815.7981 μs |    6 |  324502.66 KB |