Mark S. Miller
erights at google.com
Sat Jan 19 11:24:07 PST 2013
---------- Forwarded message ----------
From: Rajesh K Karmani <rajesh.karmani at gmail.com>
Date: Sat, Jan 19, 2013 at 8:26 AM
To: "Mark S. Miller" <erights at google.com>
Thank you for pointing me to the discussion. I subscribed to the list,
but for some reason, I could not find a way to contribute to an
I would like to contribute two comments:
1. In terms of performance, ownership transfer (implicit or explicit)
of mutable objects could be better than immutable objects
(copy-on-write semantics) in cases when both threads or actors modify
the object. In such cases, immutable object implementation will result
in three total copies, while ownership semantics will result in two
2. Ownership transfer (implicit or explicit) can also help when
communicating across machines or address spaces, specifically in
improving the efficiency of garbage collection. An object (or its
"name") that is transferred out is certainly garbage. Garbage
collection for actor-like systems is a challenge due to in-flight
messages and reverse knowledge graph. This optimization could help in
improving its performance.
On Tue, Jan 15, 2013 at 8:32 PM, Mark S. Miller <erights at google.com> wrote:
> Hi Rajesh, your work is relevant to the following discussion. But I
> didn't want to point at it without checking with you first. If you'd
> like to contribute to the discussion, you must first subscribe at
> ---------- Forwarded message ----------
> From: Mark S. Miller <erights at google.com>
> Date: Tue, Jan 15, 2013 at 6:26 PM
> To: David Bruant <bruant.d at gmail.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> 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
> producing these.
> 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
> > network.
> >> Checkpointing a program’s entire state after every event loop turn may be
> >> consid-
> >> 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?
> > David
> > 
> > http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fast
> >  Relevant article, but I'm not sure it's the best resource on the topic:
> > http://pcwalton.github.com/blog/2012/10/03/unique-pointers-arent-just-about-memory-management/
> > Le 14/01/2013 23:46, Mark S. Miller a écrit :
> >> At
> >> http://code.google.com/p/es-lab/downloads/detail?name=distr-erights-in-js.pdf
> >> 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
> >> --
> >> Cheers,
> >> --MarkM
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
More information about the es-discuss