Crate josephine [−] [src]
A library which uses JavaScript to safely manage the lifetimes of Rust data.
This library allows Rust data to be attached to JavaScript objects: the lifetime of the Rust data is then the same as the JS object it is attached to. Since JS is garbage collected, it is safe to copy and discard references to JS managed data, and allows examples like doubly-linked lists which would otherwise require reference counting. Reference counting requires dynamic checks, for example getting mutable access to reference-counted data panics if the reference count is more than 1.
The goals are:
- Use JS to manage the lifetime of Rust data.
- Allow references to JS managed data to be freely copied and discarded, relying on the garbage collector for safety.
- Maintain Rust memory safety (for example no mutable aliasing), without requiring additional static analysis such as a lint.
- Allow mutable and immutable access to Rust data via JS managed references, so we do not need to rely on interior mutability.
- Provide a rooting API to ensure that JS managed data is not garbage collected while it is being used.
To support safe access to JS managed data, the API uses a JS context, which is used as an access token to allow JS managed data to be accessed, allocated or deallocated. Mutable access to JS managed data requires mutable access to the JS context, which is how the API achieves memory safety even though JS managed references can be copied and discarded freely.
JS managed memory is split into compartments, which are separately garbage collected, so the garbage collector can avoid scanning the entire heap. The API statically tracks compartments, to ensure that there are no direct references between compartments.
The API is implemented as bindings to the SpiderMonkey JS engine, from which it borrows the garbage collector and the notions of compartment and JS context. The API allows calling into JavaScript from Rust, and calling back into Rust from JavaScript. These bindings are unsafe, and are intended for use by a trusted bindings generator.
JS-managed data
Rust data can be given to JS to manage, and then accessed,
using the JS context. The JS context is passed as a variable of type JSContext<S>
,
where the type parameter S
is used to track the state of the context.
The context comes with the permissions it grants, such as CanAlloc
and CanAccess
. These permissions are modelled as traits, for example
a context in state S
can allocate memory when S: CanAlloc
.
JS managed memory is split into compartments. Each JS context has a notion of
the current compartment, which is part of the state. A JS context in compartment
C
has type JSCompartment<S>
where S: InCompartment<C>
and C: Compartment
.
A reference to JS managed data in compartment C
, where the Rust data being
managed by JS has type T
, is given type JSManaged<C, T>
.
For example, we can give JS a Rust string to manage in compartment
C
:
fn example<C, S>(cx: &mut JSContext<S>) where S: CanAlloc + InCompartment<C>, C: Compartment, { let x: JSManaged<C, String> = cx.manage(String::from("hello")); }
and then access it:
fn example<C, S>(cx: &mut JSContext<S>, x: JSManaged<C, String>) where S: CanAccess, C: Compartment, { println!("{} world", x.borrow(cx)); }
Lifetimes of JS-managed data
Unfortunately, combining these two examples is not memory-safe, due to garbage collection:
fn unsafe_example<C, S>(cx: &mut JSContext<S>) where S: CanAlloc + CanAccess + InCompartment<C>, C: Compartment, { let x: JSManaged<C, String> = cx.manage(String::from("hello")); // Imagine something triggers GC here println!("{} world", x.borrow(cx)); }
This example is not safe, as there is nothing keeping x
alive in JS,
so if garbage collection is triggered, then x
will be reclaimed
which will drop the Rust data, and so the call to x.borrow(cx)
will be a use-after-free.
This example is not memory-safe, and fortunately fails to typecheck:
error[E0502]: cannot borrow `*cx` as immutable because it is also borrowed as mutable
--> src/lib.rs:10:35
|
8 | let x: JSManaged<C, String> = cx.manage(String::from("hello"));
| -- mutable borrow occurs here
9 | // Imagine something triggers GC here
10 | println!("{} world", x.borrow(cx));
| ^^ immutable borrow occurs here
11 | }
| - mutable borrow ends here
To see why this example fails to typecheck, we can introduce explicit lifetimes:
fn unsafe_example<'a, C, S>(cx: &'a mut JSContext<S>) where S: CanAlloc + CanAccess + InCompartment<C>, C: Compartment, { // x has type JSManaged<'b, C, String> let x = cx.manage(String::from("hello")); // Imagine something triggers GC here // x_ref has type &'c String let x_ref = x.borrow(cx); println!("{} world", x_ref); }
We can now see why this fails to typecheck: since cx
is borrowed mutably at type
&'b mut JSContext<S>
, then immutably at type &'c mut JSContext<S>
these lifetimes
cannot overlap, but the call to x.borrow(cx)
requires them to overlap. These contradicting
constraints cause the example to fail to compile.
Rooting
To fix this example, we need to make sure that x
lives long enough. One way to do this is
to root x
, so that it will not be garbage collected.
fn example<C, S>(cx: &mut JSContext<S>) where S: CanAlloc + CanAccess + InCompartment<C>, C: Compartment, { // Declare a root which will be used to keep x alive during its lifetime let ref mut root = cx.new_root(); // Store a reference to x in the root let x = cx.manage(String::from("hello")).in_root(root); // This is what is keeping x alive ------^ // Imagine something triggers GC here // The root ensures that x survives GC, so is safe to use println!("{} world", x.borrow(cx)); }
To see why this example now typechecks, we again introduce explicit lifetimes:
fn example<'a, C, S>(cx: &'a mut JSContext<S>) where S: CanAlloc + CanAccess + InCompartment<C>, C: Compartment, { // root has type JSRoot<'b, String> let ref mut root = cx.new_root(); // x has type JSManaged<'b, C, String> let x = { // x_unrooted has type JSManaged<'d, C, String> let x_unrooted = cx.manage(String::from("hello")); // By rooting it, its lifetime changes from 'd to 'b (the lifetime of the root) x_unrooted.in_root(root) }; // Imagine something triggers GC here // x_ref has type &'c String let x_ref = x.borrow(cx); println!("{} world", x_ref); }
The example typechecks because the
constraints are that 'b
overlaps with 'c
and 'd
, and that
'c
and 'd
don't overlap. These constraints are satisfiable, so the
example typechecks.
Mutating JS-managed data
JS managed data can be accessed mutably as well as immutably. This is safe because mutably accessing JS manage data requires mutably borrowing the JS context, so there cannot be two simultaneous mutable accesses.
fn example<C, S>(cx: &mut JSContext<S>, x: JSManaged<C, String>) where S: CanAccess, C: Compartment, { println!("{} world", x.borrow(cx)); *x.borrow_mut(cx) = String::from("hi"); println!("{} world", x.borrow(cx)); }
An attempt to mutably access JS managed data more than once simultaneously results in an error from the borrow-checker, for example:
fn unsafe_example<C, S>(cx: &mut JSContext<S>, x: JSManaged<C, String>, y: JSManaged<C, String>) where S: CanAccess, C: Compartment, { mem::swap(x.borrow_mut(cx), y.borrow_mut(cx)); }
error[E0499]: cannot borrow `*cx` as mutable more than once at a time
--> src/lib.rs:8:46
|
8 | mem::swap(x.borrow_mut(cx), y.borrow_mut(cx));
| -- ^^ - first borrow ends here
| | |
| | second mutable borrow occurs here
| first mutable borrow occurs here
Snapshots
Some cases of building JS managed data require rooting, but in some cases the rooting can be avoided, since the program does nothing to trigger garbage collection. In this case, we can snapshot the JS context after performing allocation. The snapshot supports accessing JS managed data, but does not support any calls that might trigger garbage collection. As a result, we know that any data which is live at the beginning of the snapshot is also live at the end.
fn example<C, S>(cx: &mut JSContext<S>) where S: CanAlloc + CanAccess + InCompartment<C>, C: Compartment, { let (ref cx, x) = cx.snapshot_manage(String::from("hello")); // Since the context is snapshotted it can't trigger GC println!("{} world", x.borrow(cx)); }
A program which tries to use a function which might trigger GC will not typecheck, as the snapshotted JS context state does not support the appropriate traits. For example:
fn unsafe_example<C, S>(cx: &mut JSContext<S>) where S: CanAlloc + CanAccess + InCompartment<C>, C: Compartment, { let (ref mut cx, x) = cx.snapshot_manage(String::from("hello")); cx.gc(); println!("{} world", x.borrow(cx)); }
In this program, the call to cx.gc()
requires the state
to support CanAlloc<C>
, which is not allowed by the snapshotted state.
error[E0277]: the trait bound `josephine::Snapshotted<'_, S>: josephine::CanAlloc` is not satisfied
--> src/lib.rs:9:8
|
9 | cx.gc();
| ^^ the trait `josephine::CanAlloc` is not implemented for `josephine::Snapshotted<'_, S>`
Working with compartments
To enter the compartment of a JS managed object, you can use cx.enter_known_compartment(managed)
.
This returns a context whose current compartment is that of the JS managed objecct.
fn example<C, S>(cx: &mut JSContext<S>, x: JSManaged<C, String>) where S: CanAccess + CanAlloc, C: Compartment, { // We can't allocate data without entering the comartment. // Commenting out the next line gives an error // the trait `josephine::InCompartment<_>` is not implemented for `S`. let ref mut cx = cx.enter_known_compartment(x); let ref mut root = cx.new_root(); let y = cx.manage(String::from("world")).in_root(root); println!("Hello, {}.", y.borrow(cx)); }
Working with named compartmens is fine when there is a fixed number of them, but not when
the number of compartments is unbounded. For example, the type Vec<JSManaged<C, T>>
contains
a vector of managed objects, all in the same compartment, but sometimes you need a vector of
objects in different compartments. This is what wildcards are for (borrowed from
Java wildcards
which solve a similar problem).
The wildcard compartment is called SOMEWHERE
, and JSManaged<SOMEWHERE, T>
refers
to JS managed data whose compartment is unknown. For example Vec<JSManaged<SOMEWHERE, T>>
contains a vector of managed objects, which may all be in different compartments.
To create a JSManaged<SOMEWHERE, T>
, we use managed.forget_compartment()
.
fn example<C, S>(cx: &mut JSContext<S>) -> JSManaged<SOMEWHERE, String> where S: CanAlloc + InCompartment<C>, C: Compartment, { cx.manage(String::from("hello")).forget_compartment() }
To access data with a wildcard compartment, first enter the compartment
using cx.enter_unknown_compartment(managed)
.
fn example<S>(cx: &mut JSContext<S>, x: JSManaged<SOMEWHERE, String>) where S: CanAccess, { // We can't access x without first entering its compartment. // Commenting out the next two lines gives an error // the trait `josephine::Compartment` is not implemented for `josephine::SOMEWHERE`. let ref mut cx = cx.enter_unknown_compartment(x); let x = cx.entered(); println!("Hello, {}.", x.borrow(cx)); }
Sometimes you need to check to see if some JS managed data is in the current compartment or not.
This is done with managed.in_compartment(cx)
, which returns an Option<JSManaged<C, T>>
when the context's current compartment is C
. The result is Some(managed)
if managed
was in
compartment C
, and None
if it was in a different compartment.
fn example<S, C>(cx: &mut JSContext<S>, x: JSManaged<SOMEWHERE, String>) where S: CanAccess + InCompartment<C>, C: Compartment, { if let Some(x) = x.in_compartment(cx) { println!("Hello, {}.", x.borrow(cx)); } }
User-defined types
There are more types to manage than just String
!
To be managed by JSManageable
, a type should implement the following traits:
JSTraceable
: values of the type can be traced, that is can tell the garbage collector which objects are reachable from them.JSLifetime
: values of the type have their lifetime managed by JS.JSCompartmental
: values of the type have their compartment managed by JS.JSInitializable
: this type knows how to initialize a JS object which is used to manage its lifetime.
Each of these traits can be derived. The fields of a JSTraceable
type should be
JSTraceable
, and similarly for JSLifetime
and JSCompartmental
. This requirement
is not true for JSInitializable
.
A typical use is to define two types: the native type NativeThing
and then the managed type Thing<'a, C>
which is just a JSManaged<'a, C, NativeThing>
.
#[derive(JSInitializable, JSTraceable, JSLifetime, JSCompartmental)] struct NativeName { name: String } #[derive(Clone, Copy, Debug, Eq, PartialEq, JSInitializable, JSTraceable, JSLifetime, JSCompartmental)] pub struct Name<'a, C> (JSManaged<'a, C, NativeName>); impl<'a, C:'a> Name<'a, C> { pub fn new<S>(cx: &'a mut JSContext<S>, name: &str) -> Name<'a, C> where S: CanAlloc + InCompartment<C>, C: Compartment, { Name(cx.manage(NativeName { name: String::from(name) })) } pub fn name<S>(self, cx: &'a JSContext<S>) -> &'a str where S: CanAccess, C: Compartment, { &*self.0.borrow(cx).name } } let ref mut root = cx.new_root(); let hello = Name::new(cx, "hello").in_root(root); assert_eq!(hello.name(cx), "hello");
Sometimes the native type will itself contain references to JS-managed data, so will need to be parameterized on a lifetime and compartment.
#[derive(JSInitializable, JSTraceable, JSLifetime, JSCompartmental)] struct NativeNames<'a, C> { names: Vec<Name<'a, C>> } #[derive(Clone, Copy, Debug, JSInitializable, JSTraceable, JSLifetime, JSCompartmental)] pub struct Names<'a, C> (JSManaged<'a, C, NativeNames<'a, C>>); impl<'a, C:'a> Names<'a, C> { pub fn new<S>(cx: &'a mut JSContext<S>) -> Names<'a, C> where S: CanAlloc + InCompartment<C>, C: Compartment, { Names(cx.manage(NativeNames { names: vec![] })) } pub fn push_str<S>(self, cx: &'a mut JSContext<S>, name: &str) where S: CanAccess + CanAlloc + InCompartment<C>, C: Compartment, { let ref mut root = cx.new_root(); let name = Name::new(cx, name).in_root(root); self.0.borrow_mut(cx).names.push(name); } pub fn get<S>(self, cx: &'a JSContext<S>, index: usize) -> Option<Name<'a, C>> where S: CanAccess, C: Compartment, { self.0.borrow(cx).names.get(index).cloned() } } let ref mut root = cx.new_root(); let hello_world = Names::new(cx).in_root(root); hello_world.push_str(cx, "hello"); hello_world.push_str(cx, "world"); assert_eq!(hello_world.get(cx, 0).map(|name| name.name(cx)), Some("hello")); assert_eq!(hello_world.get(cx, 1).map(|name| name.name(cx)), Some("world"));
Calling between JS and Rust
Josephine exposes an unsafe API to allow JS to call Rust and back again.
This is just a thin wrapper round the SpiderMonkey API.
See the ffi
module for details.
Globals
Each JS compartment has a special object called a global.
The compartment can be created using cx.create_compartment()
,
and the global can be given native data to manage with cx.global_manage(data)
.
The global can be accessed with cx.global()
.
#[derive(JSInitializable, JSTraceable, JSLifetime, JSCompartmental)] pub struct NativeMyGlobal { name: String } type MyGlobal<'a, C> = JSManaged<'a, C, NativeMyGlobal>; fn example<'a, S>(cx: &'a mut JSContext<S>) -> MyGlobal<'a, SOMEWHERE> where S: CanAccess + CanAlloc, { let cx = cx.create_compartment(); let name = String::from("Alice"); let cx = cx.global_manage(NativeMyGlobal { name: name }); cx.global().forget_compartment() }
In some cases, the global contains some JS-managed data, which is why the initialization is split into two steps: creating the compartment, and providing the JS-managed data for the global, for example:
#[derive(JSInitializable, JSTraceable, JSLifetime, JSCompartmental)] pub struct NativeMyGlobal<'a, C> { name: JSManaged<'a, C, String> } type MyGlobal<'a, C> = JSManaged<'a, C, NativeMyGlobal<'a, C>>; fn example<'a, S>(cx: &'a mut JSContext<S>) -> MyGlobal<'a, SOMEWHERE> where S: CanAccess + CanAlloc, { let mut cx = cx.create_compartment(); let ref mut root = cx.new_root(); let name = cx.manage(String::from("Alice")).in_root(root); let ref cx = cx.global_manage(NativeMyGlobal { name: name }); cx.global().forget_compartment() }
Bootstrapping
The JSContext is built using JSContext::new
.
#[derive(JSInitializable, JSTraceable, JSLifetime, JSCompartmental)] pub struct NativeMyGlobal { name: String } type MyGlobal<'a, C> = JSManaged<'a, C, NativeMyGlobal>; fn example<'a, S>(cx: &'a mut JSContext<S>) -> MyGlobal<'a, SOMEWHERE> where S: CanAccess + CanAlloc, { let cx = cx.create_compartment(); let name = String::from("Alice"); let cx = cx.global_manage(NativeMyGlobal { name: name }); cx.global().forget_compartment() } fn main() { let ref mut cx = JSContext::new(); example(cx); }
Reexports
pub use context::JSContext; |
pub use context::CanAccess; |
pub use context::CanAlloc; |
pub use context::InCompartment; |
pub use context::Initialized; |
pub use context::IsInitialized; |
pub use context::IsInitializing; |
pub use context::IsSnapshot; |
pub use compartment::SOMEWHERE; |
pub use compartment::Compartment; |
pub use compartment::JSCompartmental; |
pub use ffi::JSInitializable; |
pub use managed::JSManaged; |
pub use root::JSRoot; |
pub use root::JSLifetime; |
pub use string::JSString; |
pub use trace::JSTraceable; |
Modules
compartment | |
context | |
ffi | |
managed | |
root | |
runtime | |
string | |
trace |