josephine

JS affine

Explore on GitHub Read Hacker News discussions

4Distinct people

4Mentions

0Explicit recommenders

68GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

JS affine

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year4 dated mentions

Observed mentions: 2017-12-25 23:44:45 UTC to 2021-06-19 18:35:34 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2017	2017-01-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	1	1
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	0	0
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	1
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	1

What Hacker News says

4 sources

celeritascelery·Jun 19, 2021

For me, the most interesting one is Josephine[1]. This allows tracking of stack roots, doesn't limit the time when GC can run, and takes advantage of rust's affine type system. However I have to say the API feels fairly clunky, with the need to root everything before mutation and the need to pass context objects to every method. [1] https://github.com/asajeffrey/josephine

In A Tour of Safe Tracing GC Designs in Rust

Rusky·May 24, 2020

That's an interesting question, and there has been some work in that area. Getting shared mutability as a user of GC is basically the same as getting shared mutability in any other scenario in Rust. You use `UnsafeCell<T>` or a safe wrapper around it, like `Mutex` or `Cell`. You can get a feel for this even in idiomatic Rust using `Rc` instead of a tracing GC. When you start looking at other methods of GC things get trickier. Even with `UnsafeCell<T>` the GC can't, in general, know whether something is borrowed (mutably or immutably) by the mutator, so the problem to be solved is finding ways to enforce that there are no references into the heap at all, when collection needs to happen. But when you think about it, this is actually not so different from the usual problem of GC safepoints. The problem is the same- enforce that there are no

Read the rest

un-rooted pointers into the heap, when collection needs to happen. And it turns out there are some tricks you can do with lifetimes to get borrowck to enforce safepoints for you, and it could even be made pretty ergonomic in the future. Some early discussion of the problem space: * http://blog.pnkfx.org/blog/categories/gc/ * https://manishearth.github.io/blog/2015/09/01/designing-a-gc... * https://manishearth.github.io/blog/2016/08/18/gc-support-in-... A design from Servo, and a paper to go with it: https://github.com/asajeffrey/josephine A series of blogposts describing a more recent attempt: https://boats.gitlab.io/blog/post/shifgrethor-i/ The most recent attempt I know of: https://github.com/kyren/gc-arena/ I think gc-arena is fairly similar to josephine- both treat the GC heap itself as a container-like object, requiring `&` or `&mut` access to dereference a GC pointer. Gc-arena also suggests that we could use generator yield points as GC safepoints- they have exactly the required lifetime properties. So you might (to borrow Python syntax) `yield from fn_that_allocates_gc_memory()`, with the compiler ensuring you don't hold any references into the heap across that call.

In Chromium project finds that 70% of security defects are memory safety problems

pcwalton·Mar 7, 2019

> Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Not necessarily. If the language provides a way to ensure memory management of DOM objects is correct across language boundaries, it would provide an effective defense against these issues. Safe memory management across a combination of managed and unmanaged code is a tough problem, and Rust (and perhaps Swift?) are the only languages I know of that have any attempts to solve it. It requires both language and library support. There are several competing solutions in the community: luster [1], shifgrethor [2], and josephine [3] come to mind. All of them allow this kind of code to be implemented safely. [1]: https://github.com/kyren/luster [2]: https://github.com/withoutboats/shifgrethor [3]: https://github.com/asajeffrey/josephine

In Serious Chrome zero-day

littlestymaar·Dec 25, 2017

As an alternative GC in Rust, you also have Josephine[1], which uses the SpiderMonkey[2] GC. It's cumbersome to use though[3] and should probably not be used outside of Servo. [1]: https://github.com/asajeffrey/josephine [2]: mozilla's JS VM [3]: this is how you call a doubly linked list managed by the JS GC https://github.com/asajeffrey/josephine/blob/master/examples...

In Yew: Rust framework for making React-like client web apps