2013/11/11 Mark S. Miller erig...@google.com
Much of the early Actors research
DEC SRC Network Objects
RMI
Original-E before I arrived at Electric Communities
Midori
Orleans
AmbientTalk
Cap'n Proto
While I'm honored to see AmbientTalk listed among these systems, I should
note that,
2013/11/13 Mark S. Miller erig...@google.com
* Weak consistency (I know, people hear CAP and give up too much) won,
which surprised some.
Because Promises are asynchronous, even locally, the state of the world
when a promise-based request is made differs from the one in which the
request is
Boris Zbarsky wrote:
On 11/12/13 11:07 PM, David Bruant wrote:
I understand the need to know when a promise has an unhandled error at
development time, I'm less clear on why you need to know it at runtime.
Why would you do with this information? handle the error?
The same thing that sites
I mean the promises-unwrapping proposal that has now been accepted into
ES6 and the DOM, and IIUC is being implemented by several browser makers.
Let's call these JS Promises.
The unwrapping means that there is forced recursive synchronization,
doesn't it? When trying to work with nested
Claus, that is not how ES6 promises work. (Or their predecessors in Q and
elsewhere.) In essence, the then message sent to a promise is just one of
many, and in particular it can't be pipelined. If you were to pipeline a get
message, you wouldn't do so via the then mechanism. More on this can
On 11/12/13 11:07 PM, David Bruant wrote:
I understand the need to know when a promise has an unhandled error at
development time, I'm less clear on why you need to know it at runtime.
Why would you do with this information? handle the error?
The same thing that sites (e.g. Facebook) do with
On Tue, Nov 12, 2013 at 8:07 PM, David Bruant bruan...@gmail.com wrote:
Le 12/11/2013 13:42, Kris Kowal a écrit :
One of the concerns with promises is that they consume exceptions that
may or may not be handled.
...
I understand the need to know when a promise has an unhandled error at
Le 13/11/2013 06:15, Boris Zbarsky a écrit :
On 11/12/13 11:07 PM, David Bruant wrote:
I understand the need to know when a promise has an unhandled error at
development time, I'm less clear on why you need to know it at runtime.
Why would you do with this information? handle the error?
The
On 11/13/13 10:58 AM, David Bruant wrote:
I'm sympathetic with this use case, but Weakrefs seem like the wrong
tool to solve this problem.
I think I agree on that.
Ideally, the ECMAScript error sink would handled both uncaught thrown
errors and unhandled promise errors.
Defining unhandled
On Nov 13, 2013, at 7:58 AM, David Bruant wrote:
...
The browser has window.onerror for historical reasons, Node.js introduced
Domains and Domain#intercept [1] for that reason IIUC.
Isn't it the sign that ECMAScript should have this feature built-in?
A global sink has something absurd to
Could I present another example where WeakRef are required.
I am writing an object management layer similar to what exist in other language
and systems. One of the requirement is uniquing so that each object exist only
once in memory. Let say I retrieve a company and its employees and later
Hi Pierre, as long as this use would not need inter-realm weakrefs to be
weak, as seems likely, then I think it could live fine with the existing
proposal for securing weakrefs. No need to tilt any balance away from
security.
On Tue, Nov 12, 2013 at 10:18 AM, Pierre Frisch
Mark S. Miller wrote:
Much of the early Actors research
DEC SRC Network Objects
RMI
Original-E before I arrived at Electric Communities
Midori
Orleans
AmbientTalk
Cap'n Proto
Mark (and Tom, cc'ed), please take this as sincere feedback from a fan
-- I mean this in the best possible way:
I
With the introduction of custom elements I find myself more and more
interested in script that is tightly coupled to DOM nodes but that can be
safely spun down when that node is GC'd (not just lifecycle removed).
This could be achieved by having a callback on weakmaps or some way to hook
into the
On Mon, Nov 11, 2013 at 3:51 PM, Mark S. Miller erig...@google.com wrote:
Much of the early Actors research
DEC SRC Network Objects
RMI
Original-E before I arrived at Electric Communities
[...]
Sure. I can only echo Brendan's critique. None of the projects you
listed are in JS, most are
Matthew Robb wrote:
With the introduction of custom elements I find myself more and more
interested in script that is tightly coupled to DOM nodes but that can
be safely spun down when that node is GC'd (not just lifecycle
removed). This could be achieved by having a callback on weakmaps or
Le 12/11/2013 10:18, Pierre Frisch a écrit :
Could I present another example where WeakRef are required.
I am writing an object management layer similar to what exist in other language
and systems. One of the requirement is uniquing so that each object exist only
once in memory. Let say I
(factoring out this part of the conversation because it seems like a
bit of a sidetrack)
Mark and me:
Why do you believe manual deallocation decisions will be easier in
distributed systems than they are locally?
I don't. That's why I cited several examples of systems that require
neither
On Tue, Nov 12, 2013 at 11:23 AM, Jason Orendorff jason.orendo...@gmail.com
wrote:
(factoring out this part of the conversation because it seems like a
bit of a sidetrack)
Mark and me:
Why do you believe manual deallocation decisions will be easier in
distributed systems than they are
On Tue, Nov 12, 2013 at 11:10 AM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On Mon, Nov 11, 2013 at 3:51 PM, Mark S. Miller erig...@google.com
wrote:
Much of the early Actors research
DEC SRC Network Objects
RMI
Original-E before I arrived at Electric Communities
[...]
Sure.
One of the concerns with promises is that they consume exceptions that may
or may not be handled. I have been looking forward for WeakRef as one of
the avenues available to mitigate this problem. A post-mortem finalizer
would be able to surface an error that was trapped by a promise or promises
On Tue, Nov 12, 2013 at 10:49 AM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
Much of the early Actors research
DEC SRC Network Objects
RMI
Original-E before I arrived at Electric Communities
Midori
Orleans
AmbientTalk
Cap'n Proto
Mark (and Tom, cc'ed), please take
Mark S. Miller wrote:
I don't think it does in practice, any more than UNIX does. How does a
UNIX admin (or the kernel) decide when to kill a process?
Good question. How do they?
Old-style Unix admin involves dedicating process seats, doing shallow
supervision-tree-style
Just to be clear on my use case. I am not trying to build distributed objects.
I am building an object management layer similar to what EOF/WebObjects was.
The purpose is to expose in the client a graph of object for display and
edition. The purpose of this is to simplify writing client side
Mark S. Miller wrote:
Link please for the Stonebreaker point?
Sorry, having a hard time finding it now. It was about the longer
history since SQL was pioneered; also about NoSQL.
On your other bullets, you're preaching to the choir. These are
exactly the considerations that led to the E
On 11/12/13 2:01 PM, Matthew Robb wrote:
Perhaps somewhere in the middle would work, something like a regular map
but that also pays attention to the ref count changes of key and an
author can hook in with a callback that effectively means reached 1 ref.
Consider this testcase:
var elem =
Mark S. Miller wrote:
However, many clients will engage in honest GC to keep their
requirements on
service memory low. Many services will not need to cut such
clients off
because of excessive resource demands.
Perhaps, but they still need to cut off bad clients, and
I mean the promises-unwrapping proposal that has now been accepted into ES6
and the DOM, and IIUC is being implemented by several browser makers. Let's
call these JS Promises. These descend from Promises/A+ which have a long
and complicated history, but the major branches of that history all to
On Tue, Nov 12, 2013 at 4:16 PM, Brendan Eich bren...@mozilla.com wrote:
Mark S. Miller wrote:
However, many clients will engage in honest GC to keep their
requirements on
service memory low. Many services will not need to cut such
clients off
because of excessive
In summarizing the history, I held back from mentioning names because it is
a long history and many people deserve thanks. Nevertheless, a few names
stand out so much I can't talk about the history without thanking them:
E. Dean Tribble
Domenic Denicola
Kris Kowal
Tyler Close
Without them,
On Nov 12, 2013, at 4:30 PM, Mark S. Miller wrote:
Nevertheless, remember that I am not yet asking TC39 to standardize
distributed JS itself, and will not until we have some cowpaths. The ES7
question is only regarding the remaining necessary primitive to start these
paving efforts --
On Tue, Nov 12, 2013 at 6:19 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Nov 12, 2013, at 4:30 PM, Mark S. Miller wrote:
Nevertheless, remember that I am not yet asking TC39 to standardize
distributed JS itself, and will not until we have some cowpaths. The ES7
question is
Le 12/11/2013 13:42, Kris Kowal a écrit :
One of the concerns with promises is that they consume exceptions that
may or may not be handled. I have been looking forward for WeakRef as
one of the avenues available to mitigate this problem. A post-mortem
finalizer would be able to surface an
Finding out at runtime (by doing a sanity check in the finalizer) is a way
to catch bugs in the application that were not caught at
compile/development time, so you can log/report them and go back and fix
them. This is an incredibly useful facility since (generally speaking)
promise libraries have
On Fri, Nov 8, 2013 at 1:35 PM, Mark S. Miller erig...@google.com wrote:
(re: weakrefs and post-mortem finalization)
They are needed for many other things, such as
distributed acyclic garbage collection (as in adapting the CapTP ideas to
distributed JS).
I'm not convinced acyclic distributed
On Mon, Nov 11, 2013 at 9:25 AM, Jason Orendorff
jason.orendo...@gmail.comwrote:
On Fri, Nov 8, 2013 at 1:35 PM, Mark S. Miller erig...@google.com wrote:
(re: weakrefs and post-mortem finalization)
They are needed for many other things, such as
distributed acyclic garbage collection (as in
I haven't been able to read through all of this very thoroughly but I would
like to inject that I have a use case right now for some sort of callback
on a WeakMap that notifies AFTER the key has been GC'd but before the value
has been released. If this already exists and I just can't locate it I
On 11/11/13 2:43 PM, Matthew Robb wrote:
I haven't been able to read through all of this very thoroughly but I
would like to inject that I have a use case right now for some sort of
callback on a WeakMap that notifies AFTER the key has been GC'd but
before the value has been released.
What I am suggesting would not be bound to a WeakRef rather to the WeakMap.
So in my mind it seems like the WeakMap can maintain a strong ref to the
values it stores (not the keys obviously) and before the value get's
removed from that WeakMap, fire off a notifier.
On Mon, Nov 11, 2013 at 11:46
On 11/11/13 2:51 PM, Matthew Robb wrote:
What I am suggesting would not be bound to a WeakRef rather to the
WeakMap. So in my mind it seems like the WeakMap can maintain a strong
ref to the values it stores (not the keys obviously)
The whole point of a weakmap is that it does not maintain a
On Mon, Nov 11, 2013 at 12:12 PM, Mark S. Miller erig...@google.com wrote:
On Mon, Nov 11, 2013 at 9:25 AM, Jason Orendorff jason.orendo...@gmail.com
JS users do not want RPC systems where one process's memory usage
depends on getting per-object callbacks from an untrusted peer's GC
On Mon, Nov 11, 2013 at 1:09 PM, Jason Orendorff
jason.orendo...@gmail.comwrote:
On Mon, Nov 11, 2013 at 12:12 PM, Mark S. Miller erig...@google.com
wrote:
On Mon, Nov 11, 2013 at 9:25 AM, Jason Orendorff
jason.orendo...@gmail.com
JS users do not want RPC systems where one process's
(parenthetical aside replying to a parenthetical aside!
Mark S. Miller wrote:
If anything, local manual deallocation should be easier, and these
have already proven hard enough that people (except C++
and Rust
programmers) have turned to local GC.
/be)
On Thu, Nov 7, 2013 at 6:40 PM, K. Gadd k...@luminance.org wrote:
To contrive a scenario that might illustrate where event listeners aren't
necessarily enough: Let's say I have an entity system for a game that is
modelling thousands of independent entities that interact. In this system,
entity
Le 08/11/2013 17:09, Jason Orendorff a écrit :
(As a bonus, the weirdness will happen in one implementation and not
another, and you and your users will blame the implementation. So
there will be pressure on implementers to reduce the nondeterminism by
doing GC more frequently—which trades off
Please try -- such experiments are interesting. But even if this experiment
is successful, I hope and expect that we'll have weakrefs and post-mortem
finalization in ES7. They are needed for many other things, such as
distributed acyclic garbage collection (as in adapting the CapTP ideas to
More tooling is great for developing new software in ES, but it does
nothing to address use cases where existing software and algorithms can't
be ported without Weak References. Perhaps enough research will allow us to
arrive at some sort of general 'best practice' for replacing the use of
weak
On Nov 7, 2013, at 3:16 PM, Mark Miller wrote:
I agree. This is a good use for weakrefs without the need for finalization.
Thanks!
On Thu, Nov 7, 2013 at 3:12 PM, K. Gadd k...@luminance.org wrote:
The problem is that the cycles remain uncollectable for a very long period of
time, even
The difference is that if the large cycle is only uncollected because the
weak references haven't been zapped, in a low memory/out of memory
situation, the runtime's collector can go through and zap all weak
references. If I write an ES application and do my own cycle
collection/weak reference
Le 08/11/2013 20:35, Mark S. Miller a écrit :
Please try -- such experiments are interesting.
I am :-)
But even if this experiment is successful, I hope and expect that
we'll have weakrefs and post-mortem finalization in ES7. They are
needed for many other things, such as distributed acyclic
Hi David, there's a distributed race condition that's fixed by the use of
importCount. Fixing it using post-mortem finalization creates a local race
condition which is fixed by this test, not if the proxy is *still* alive,
but if a new proxy has been installed as its reincarnation.
For
On 11/06/2013 07:37 PM, K. Gadd wrote:
Generally speaking, all the discussions on this list about WRs so far have
not suggested that there is any way to introduce WeakRefs without making GC
behavior observable in some fashion. WeakRefs functionally make GC
observable because when you try to
When I talk about the importance of weak references I am *not* talking
about the importance of finalization for managing native/remote resources;
that's an important consideration but it's a separate one. When I talk
about why weak references are important, I mean for the purposes of
building
Could you give an example, hopefully simple, of such a problem you can
solve better with GC + weakmaps + weakrefs but without finalization, vs
just GC + weakmaps ? Thanks.
On Thu, Nov 7, 2013 at 1:46 PM, K. Gadd k...@luminance.org wrote:
When I talk about the importance of weak references I am
I'll try and restate an example I used before.
Let's say you're building a somewhat simple tab-based application, where
each tab represents a different 'mode'. In this case, you need a higher
level coordinating object that manages the tab bar, and it needs to own
references to all of the active
That example looks to me like it could be implemented with WeakMap instead
of WeakRef. Am I missing something?
On Thu Nov 07 2013 at 2:43:45 PM, K. Gadd k...@luminance.org wrote:
I'll try and restate an example I used before.
Let's say you're building a somewhat simple tab-based application,
I am not aware of any way to implement my described scenario using WeakMaps
without having the same cycle collection issues. I haven't seen any
examples of WeakMap used for this in the wild either.
On Thu, Nov 7, 2013 at 2:48 PM, felix lee feli...@gmail.com wrote:
That example looks to me like
Ah, sorry, I misread your description of the relationships. Yeah, that
would be hard to do with WeakMaps.
On Thu Nov 07 2013 at 3:02:02 PM, K. Gadd k...@luminance.org wrote:
I am not aware of any way to implement my described scenario using
WeakMaps without having the same cycle collection
Le 07/11/2013 22:46, K. Gadd a écrit :
That's the sort of obstacle that factors into a developer's choice of
language and toolset. I've seen this particular concern with ES crop
up in the past on real projects, and I've seen firsthand how difficult
it is to avoid uncollectable cycles in a
The problem is that the cycles remain uncollectable for a very long period
of time, even though functionally the references don't need to be strong.
On Thu, Nov 7, 2013 at 3:10 PM, David Bruant bruan...@gmail.com wrote:
Le 07/11/2013 22:46, K. Gadd a écrit :
That's the sort of obstacle that
I agree. This is a good use for weakrefs without the need for finalization.
Thanks!
On Thu, Nov 7, 2013 at 3:12 PM, K. Gadd k...@luminance.org wrote:
The problem is that the cycles remain uncollectable for a very long period
of time, even though functionally the references don't need to be
Would someone be interested in putting together a small code example, before
and after weak refs, illustrating this situation? I have a feeling this
conversation will be referenced in many future threads, and the added clarity
of code would be greatly helpful.
On 7 Nov 2013, at 18:16, Mark
On Thu, Nov 7, 2013 at 11:42 PM, K. Gadd k...@luminance.org wrote:
I'll try and restate an example I used before.
Let's say you're building a somewhat simple tab-based application, where
each tab represents a different 'mode'. In this case, you need a higher
level coordinating object that
Please reread my example, events are a part of it but it is not exclusively
about events. My example explicitly demonstrates the modes holding
references in *both* directions, and only one of them is an event listener.
You're correct that weak event listeners solve some of the problems that
are
On Thu, Nov 7, 2013 at 4:27 PM, Marius Gundersen gunder...@gmail.comwrote:
It seems that every (real) usecase for weakRefs, weakMaps and weakSets is
to implement a weak event listener system.
Not true. Even silly.
Unfortunately weak event listeners cannot be implemented with the current
On Nov 8, 2013 1:46 AM, Mark Miller erig...@gmail.com wrote:
On Thu, Nov 7, 2013 at 4:27 PM, Marius Gundersen gunder...@gmail.com
wrote:
It seems that every (real) usecase for weakRefs, weakMaps and weakSets
is to implement a weak event listener system.
Not true. Even silly.
Sorry, I may
Over lunch I was discussing ES6 and ES7 features with some developers doing
JavaScript crypto, and they mentioned an interest in not only weak references,
but weak callbacks. That is, a notification when your object gets garbage
collected, similar (I think) to what V8 has with its `MakeWeak
On Wed, Nov 6, 2013 at 10:49 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Over lunch I was discussing ES6 and ES7 features with some developers
doing JavaScript crypto, and they mentioned an interest in not only weak
references, but weak callbacks. That is, a notification when your
Thanks Mark for the education, especially on the pre- vs. post-morterm
finalization distinction. I don't think I was specifically advocating for
pre-mortem in my OP, since I didn't really understand the difference :P.
Post-mortem finalization sounds quite reasonable. What do people think of
It is part of the WeakRefs proposal. Always has been.
On Wed, Nov 6, 2013 at 11:15 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Thanks Mark for the education, especially on the pre- vs. post-morterm
finalization distinction. I don't think I was specifically advocating for
Are these callbacks triggered for the garbage collection of any object
or just weakrefs?
They could be useful to help track down memory leaks, although the
tooling in Chrome is quite good for that.
On Wed, Nov 6, 2013 at 7:15 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Thanks Mark
First, I'll cheekily answer what you asked instead of what you meant to ask:
One of the important properties of post-mortem finalization is that it is
*not* triggered by the collection of the weakref itself, and is not
triggered if the weakref is co-condemned with the object it points at.
On
On Wed, Nov 6, 2013 at 2:15 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Thanks Mark for the education, especially on the pre- vs. post-morterm
finalization distinction. I don't think I was specifically advocating for
pre-mortem in my OP, since I didn't really understand the
On Wed, Nov 6, 2013 at 3:23 PM, Oliver Hunt oli...@apple.com wrote:
On Nov 6, 2013, at 3:14 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Wed, Nov 6, 2013 at 2:15 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Thanks Mark for the education, especially on the pre- vs.
The handler gets notified by the garbage collector. There are two
conventional ways for this to be specific to the object being gc'ed.
1) Just create a unique handler for each weakref registration. If *this*
handler gets notified, then it knows that the object it was about has been
gc'ed.
2)
Generally speaking, all the discussions on this list about WRs so far have
not suggested that there is any way to introduce WeakRefs without making GC
behavior observable in some fashion. WeakRefs functionally make GC
observable because when you try to get at the target of the weakref, you
either
On Wed, Nov 6, 2013 at 7:37 PM, K. Gadd k...@luminance.org wrote:
Generally speaking, all the discussions on this list about WRs so far have
not suggested that there is any way to introduce WeakRefs without making GC
behavior observable in some fashion. WeakRefs functionally make GC
77 matches
Mail list logo
