4 ms·

It's awesome to see work on concurrency, but I'd really like to se a model that didn't involve shared memory. JavaScript on the web already has the concept of

It's awesome to see work on concurrency, but I'd really like to se a model that didn't involve shared memory. JavaScript on the web already has the concept of Transferrables. It'd be great to explore how user-land code could create transferrable objects and graphs of them so they could be sent between threads without threads sharing the same heap.

amelius 9y ago
Sorry, but we need shared memory for fast sharing of large immutable data structures.
- Jtsummers 9y ago
  Shared memory could be hidden from the users. Passing objects would really be passing control of objects. If process A creates object a, and passes it to process B, no copying has to happen if the underlying mechanism uses shared memory and access control to effect the transfer (a change of owner).
  - spankalee 9y ago
    Yes. Presumably transferrable objects would have to be created on a shared heap. Non-transferrables would live on thread-local heaps.
    - pizlonator 9y ago
      I find that thinking about multiple heaps is harder than thinking about threads. (Ever programmed with scoped memory? It's a nightmare.) I find that thinking about transferrables is harder than thinking about threads. It's gross that an object suddenly loses all of its state just to give that object to another thread. Then, other parts of your code that still want access to that data have to do things that are definitely more gross than acquiring a lock.
      - amelius 9y ago
        You don't need locks to access immutable objects (except perhaps for garbage collection). But I agree that transferring control is a bad idea.
- spankalee 9y ago
  Then add immutable objects to JS, which enable a host of other optimizations and are useful in single-threaded contexts too. Shared-memory multithreading is just very difficult to use correctly. Actor-style concurrency hasn't really caught on (possibly because of the poor performance of workers and postMessage), but there is probably a middle ground that's easier for developers to get right.
  - phailhaus 9y ago
    JS already supports immutable objects, by using Object.freeze().
    - spankalee 9y ago
      That's not deeply immutable like you'd want for sharing objects across threads, or even for using in contexts like React and Redux.
      - phailhaus 9y ago
        Not too hard to call Object.freeze() recursively to get the deep immutability you need. And of course there's ImmutableJS for other immutable data structures.
    - bzbarsky 9y ago
      That doesn't really make things immutable. Even ignoring the deep vs shallow issue, consider what effect Object.freeze has on a JS Map (hint: none, really; you can still add/remove things).
      - phailhaus 9y ago
        Right, that's where libraries like ImmutableJS come in.
  - amelius 9y ago
    I don't think it is a good idea to stray away from the bare metal in this case. We're trying to bootstrap other languages on top of JS. They can introduce their own abstractions to shield off the programmer. Just my 2ct.
kllrnohj 9y ago
It'd also be nice if immutable objects could just be shared instead of copied or transferred instead of the current situation where they are copied and then made mutable.
- alayek 9y ago
  > instead of the current situation where they are copied and then made mutable. Could you share an example? As far as I understand, Immutable JS uses something like a trie for structural sharing and avoids memory leaks.
  - kllrnohj 9y ago
    When you send the result of Object.freeze() to or from a WebWorker the object is still copied and comes out the other side as fully mutable (aka, not frozen). Immutable JS is orthogonal in this case. That's "just" a fancy wrapper on top of a bunch of regular, mutable JS objects that makes it look immutable. It's not truly immutable to the runtime, and has no special interaction with webworkers as a result. It gets deep copied just like any other object.
pizlonator 9y ago
As someone who writes a lot of concurrent and parallel code, I can tell you it's easier to do it if the language is not imposing artificial constraints. Also, most kinds of concurrency models will probably require the underlying VM to support some kind of shared memory. That's what this post is about.
- spankalee 9y ago
  User-land Transferrables would obviously need to be implemented with shared memory, otherwise you could just use the existing structured clone operation. This post isn't just about an underlying shared memory model, concurrent access to objects and variables is exposed to users, and enabled by default. That's a huge footgun that I thought the PL world was moving away from.
  - pizlonator 9y ago
    Threads are quite successful in the real world. I think it's because the alternatives are either harder, less capable, less scalable, or even more of a footgun.
  - BatFastard 9y ago
    I personally love the idea of of transferable objects, this could work very well in an event driven architecture.

amelius 9y ago

Sorry, but we need shared memory for fast sharing of large immutable data structures.

Jtsummers 9y ago
Shared memory could be hidden from the users. Passing objects would really be passing control of objects. If process A creates object a, and passes it to process B, no copying has to happen if the underlying mechanism uses shared memory and access control to effect the transfer (a change of owner).
- spankalee 9y ago
  Yes. Presumably transferrable objects would have to be created on a shared heap. Non-transferrables would live on thread-local heaps.
  - pizlonator 9y ago
    I find that thinking about multiple heaps is harder than thinking about threads. (Ever programmed with scoped memory? It's a nightmare.) I find that thinking about transferrables is harder than thinking about threads. It's gross that an object suddenly loses all of its state just to give that object to another thread. Then, other parts of your code that still want access to that data have to do things that are definitely more gross than acquiring a lock.
    - amelius 9y ago
      You don't need locks to access immutable objects (except perhaps for garbage collection). But I agree that transferring control is a bad idea.
spankalee 9y ago
Then add immutable objects to JS, which enable a host of other optimizations and are useful in single-threaded contexts too. Shared-memory multithreading is just very difficult to use correctly. Actor-style concurrency hasn't really caught on (possibly because of the poor performance of workers and postMessage), but there is probably a middle ground that's easier for developers to get right.
- phailhaus 9y ago
  JS already supports immutable objects, by using Object.freeze().
  - spankalee 9y ago
    That's not deeply immutable like you'd want for sharing objects across threads, or even for using in contexts like React and Redux.
    - phailhaus 9y ago
      Not too hard to call Object.freeze() recursively to get the deep immutability you need. And of course there's ImmutableJS for other immutable data structures.
  - bzbarsky 9y ago
    That doesn't really make things immutable. Even ignoring the deep vs shallow issue, consider what effect Object.freeze has on a JS Map (hint: none, really; you can still add/remove things).
    - phailhaus 9y ago
      Right, that's where libraries like ImmutableJS come in.
- amelius 9y ago
  I don't think it is a good idea to stray away from the bare metal in this case. We're trying to bootstrap other languages on top of JS. They can introduce their own abstractions to shield off the programmer. Just my 2ct.

kllrnohj 9y ago

It'd also be nice if immutable objects could just be shared instead of copied or transferred instead of the current situation where they are copied and then made mutable.

alayek 9y ago
> instead of the current situation where they are copied and then made mutable. Could you share an example? As far as I understand, Immutable JS uses something like a trie for structural sharing and avoids memory leaks.
- kllrnohj 9y ago
  When you send the result of Object.freeze() to or from a WebWorker the object is still copied and comes out the other side as fully mutable (aka, not frozen). Immutable JS is orthogonal in this case. That's "just" a fancy wrapper on top of a bunch of regular, mutable JS objects that makes it look immutable. It's not truly immutable to the runtime, and has no special interaction with webworkers as a result. It gets deep copied just like any other object.

pizlonator 9y ago

As someone who writes a lot of concurrent and parallel code, I can tell you it's easier to do it if the language is not imposing artificial constraints. Also, most kinds of concurrency models will probably require the underlying VM to support some kind of shared memory. That's what this post is about.

spankalee 9y ago
User-land Transferrables would obviously need to be implemented with shared memory, otherwise you could just use the existing structured clone operation. This post isn't just about an underlying shared memory model, concurrent access to objects and variables is exposed to users, and enabled by default. That's a huge footgun that I thought the PL world was moving away from.
- pizlonator 9y ago
  Threads are quite successful in the real world. I think it's because the alternatives are either harder, less capable, less scalable, or even more of a footgun.
- BatFastard 9y ago
  I personally love the idea of of transferable objects, this could work very well in an event driven architecture.