Mark S. Miller
erights at google.com
Tue Jan 15 18:26:36 PST 2013
Hi David, E uses a different trick. E objects that are marked as
transitively immutable and transitively identity-less can be safely
passed between vats in one address space by pointer sharing rather
than copying. For these objects, this optimization has no semantics.
JS has no identity-less objects, but rivertrail does traffic in
transitively immutable nested data arrays -- both consuming and
The reason is the same -- concurrent access is not detectably
different access to a separate per-thread copy (identity aside).
Perhaps rivertrail and communicating event loops, for parallelism and
concurrency respectively, can agree on the same set of transitively
immutable data types that can safely be concurrently accessed.
This is not to argue against exclusive ownership transfer -- that may
be valuable too. But exclusive ownership transfer is more complicated:
To avoid introducing yet another new category of object but still be
able to have a revoked behavior in the donating vat, we'd have to
define transferables as proxies, as I think you argue on similar
grounds. This seems strange for an object whose purpose is high speed
Note that neither of these optimizations help or hurt when
communicating between address spaces or machines.
On Tue, Jan 15, 2013 at 2:20 AM, David Bruant <bruant.d at gmail.com> wrote:
> Hi Mark,
> I have a couple of comments:
> * On the share-nothing model
> This comment goes beyond the paper, but I think is relevant for future work.
> share-nothing model has limitations. In my opinion, one of the reasons
> WebWorkers aren't used is that the share-nothing model imposes to copy data
> when one wants 2 WebWorkers to communicate.
> Rust introduced the notion of unique pointer  for equivalent reasons.
> Adding a notion of (implicit) ownership could be a lead to follow
> (especially for the event loop work in ES7). It would however create a
> breach in the uniform vat model which abstracts out whether 2 vats are on
> the same machine or not. But I think it's a worthwhile addition.
> * Web-key
> It's probably a nit, but worth mentioning. Web-keys like
> https://www.example.com/app/#mhbqcmmva5ja3 only work on the web with a web
> application taking the fragment and building another url like
> https://www.example.com/app/?s=mhbqcmmva5ja3 with it, because the fragment
> part of a URL is a client-side only thing and is never sent over the
>> Checkpointing a program’s entire state after every event loop turn may be
>> ered costly. Ken takes care to only store those parts of the heap to disk
>> that are updated during a turn. Further, the availability of cheap
>> low-latency non-volatile memory (such as solid-state drives) has driven down
>> the cost of writing state to “disk” to the point that making micro-snapshots
>> after every turn becomes practical.
> Out of curiosity, have you measured how much these micro-snapshots take? If
> so, what are the results/order of magnitude?
>  Relevant article, but I'm not sure it's the best resource on the topic:
> Le 14/01/2013 23:46, Mark S. Miller a écrit :
>> Paper for invited talk at ESOP2013 http://www.etaps.org/2013/esop13
>> Final already submitted, but comments of course appreciated anyway.
>> Mark S. Miller
>> Tom Van Cutsem
>> Bill Tulloh
>> Contracts enable mutually suspicious parties to cooperate safely
>> through the exchange of rights. Smart contracts are programs whose
>> behavior enforces the terms of the contract. This paper shows how such
>> contracts can be specified elegantly and executed safely, given an
>> appropriate distributed, secure, persistent, and ubiquitous
>> significantly extended to deal with the other aspects. The first part
>> into this fabric. To demonstrate the suitability of this design, we
>> describe an escrow exchange contract implemented in 42 lines of
>> es-discuss mailing list
>> es-discuss at mozilla.org
More information about the es-discuss