{"action":"created","issue":{"url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/59","repository_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem","labels_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/59/labels{/name}","comments_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/59/comments","events_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/59/events","html_url":"https://github.com/tc39/ecmascript_sharedmem/issues/59","id":132123560,"number":59,"title":"Appropriateness for wasm","user":{"login":"lars-t-hansen","id":4823190,"avatar_url":"https://avatars.githubusercontent.com/u/4823190?v=3","gravatar_id":"","url":"https://api.github.com/users/lars-t-hansen","html_url":"https://github.com/lars-t-hansen","followers_url":"https://api.github.com/users/lars-t-hansen/followers","following_url":"https://api.github.com/users/lars-t-hansen/following{/other_user}","gists_url":"https://api.github.com/users/lars-t-hansen/gists{/gist_id}","starred_url":"https://api.github.com/users/lars-t-hansen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lars-t-hansen/subscriptions","organizations_url":"https://api.github.com/users/lars-t-hansen/orgs","repos_url":"https://api.github.com/users/lars-t-hansen/repos","events_url":"https://api.github.com/users/lars-t-hansen/events{/privacy}","received_events_url":"https://api.github.com/users/lars-t-hansen/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/labels/Review","name":"Review","color":"fbca04"}],"state":"open","locked":false,"assignee":null,"milestone":{"url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/milestones/2","html_url":"https://github.com/tc39/ecmascript_sharedmem/milestones/Stage%203","labels_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/milestones/2/labels","id":1545373,"number":2,"title":"Stage 3","description":"Issue that has to be resolved before the proposal can go to Stage 3. ","creator":{"login":"lars-t-hansen","id":4823190,"avatar_url":"https://avatars.githubusercontent.com/u/4823190?v=3","gravatar_id":"","url":"https://api.github.com/users/lars-t-hansen","html_url":"https://github.com/lars-t-hansen","followers_url":"https://api.github.com/users/lars-t-hansen/followers","following_url":"https://api.github.com/users/lars-t-hansen/following{/other_user}","gists_url":"https://api.github.com/users/lars-t-hansen/gists{/gist_id}","starred_url":"https://api.github.com/users/lars-t-hansen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lars-t-hansen/subscriptions","organizations_url":"https://api.github.com/users/lars-t-hansen/orgs","repos_url":"https://api.github.com/users/lars-t-hansen/repos","events_url":"https://api.github.com/users/lars-t-hansen/events{/privacy}","received_events_url":"https://api.github.com/users/lars-t-hansen/received_events","type":"User","site_admin":false},"open_issues":16,"closed_issues":0,"state":"open","created_at":"2016-01-27T00:25:31Z","updated_at":"2016-02-08T11:57:19Z","due_on":null,"closed_at":null},"comments":1,"created_at":"2016-02-08T11:57:19Z","updated_at":"2016-02-08T18:59:11Z","closed_at":null,"body":"(Visibility: @jfbastien, @lukewagner, @sunfishcode)\r\n\r\nWasm does not yet have a model for shared memory and atomics but I know it has been discussed.  And I've already received some feedback from the wasm stakeholders (some of which are cc'd).  What I'd like to have at this point is *written feedback, specifically in this ticket,* that the design outlined for shared memory in JS is not seen as conflicting in significant ways with the design one has envisioned for wasm.  (Or, or course, a discussion of any conflicts :) This is due-diligence work for getting the shared memory spec to Stage 3 in TC39.\r\n\r\nI realize that what we have for JS is a subset of what we want for wasm, eg, in the JS spec there are only seq_cst atomics, and the definition of isLockFree is fairly weak.  What I want to be sure is that any limitations in the JS spec do not get in the way of providing wasm with something more; that, while the limitations will impact wasm code that interacts with JS, they will be compatible with whatever wasm will eventually design in."},"comment":{"url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/comments/181520114","html_url":"https://github.com/tc39/ecmascript_sharedmem/issues/59#issuecomment-181520114","issue_url":"https://api.github.com/repos/tc39/ecmascript_sharedmem/issues/59","id":181520114,"user":{"login":"jfbastien","id":298127,"avatar_url":"https://avatars.githubusercontent.com/u/298127?v=3","gravatar_id":"","url":"https://api.github.com/users/jfbastien","html_url":"https://github.com/jfbastien","followers_url":"https://api.github.com/users/jfbastien/followers","following_url":"https://api.github.com/users/jfbastien/following{/other_user}","gists_url":"https://api.github.com/users/jfbastien/gists{/gist_id}","starred_url":"https://api.github.com/users/jfbastien/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jfbastien/subscriptions","organizations_url":"https://api.github.com/users/jfbastien/orgs","repos_url":"https://api.github.com/users/jfbastien/repos","events_url":"https://api.github.com/users/jfbastien/events{/privacy}","received_events_url":"https://api.github.com/users/jfbastien/received_events","type":"User","site_admin":false},"created_at":"2016-02-08T18:59:11Z","updated_at":"2016-02-08T18:59:11Z","body":"At a high-level, yes SAB's design is in line with wasm. We'll want both to be able to communicate through atomics and futex / synchronic so having a compatible model is important.\r\n\r\nSpecifically:\r\n* non-lock-free atomics should use the same synchronization mechanism between the two (e.g. lock shard).\r\n* Futex / synchronic must be able to wait on the same ID and wakeup each other.\r\n* Atomics must remain address-free in both cases.\r\n* If JS ends up only having `seq_cst` and wasm has more then we have to ensure the memory models work together (the memory model must ensure accesses on both sides synchronize with each other as if they were from the same memory model).\r\n* JS can't start supporting other memory model primitives which wasm doesn't know about without making sure both memory models are compatible.\r\n\r\nIn C++ this would look like shared memory (from C++ wasm's perspective JS is doing external modifications to the shared heap) so C++ wasm code should use `volatile atomic`. This implies that post-translation from C++ atomics have `volatile atomic` semantics, or we add a `volatile` qualifier to identify memory locations which are potentially externally modified (or we add a \"not-volatile\" qualifier in a future revision, loosening the memory model without breaking existing code)."}}