- Where: zoom.us
- When: November 7th, 5pm-6pm UTC (November 7th, 9am-10am Pacific Time)
- Location: link on calendar invite
None required if you've attended before. Send an email to the acting WebAssembly CG chair to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Proposals and discussions
- Announcement: Updates to the consensus process document to include online meetings PR [Deepti Gandluri, 5 mins]
- Memory control: Proposal update and Implementation report [Deepti Gandluri, Ryan Hunt, 40 mins]
- Freezable/Sealable GC values and globals proposal [Pierre Chambart, 15 mins]
- Poll for phase 1
- Closure
None
None
- Deepti Gandluri
- Thomas Lively
- Alon Zakai
- Andreas Rossberg
- Andrew Brown
- Ashley Nelson
- Asumu Takikawa
- Behnaz Pourmohseni
- Ben Green
- Ben Visness
- Brendan Dahl
- Chris Woods
- Daniel Hillerström
- Daniel Lehmann
- Dennis
- Emily Ruppel
- Fedor Smirnov
- Francis McCabe
- Heejin Ahn
- Ilya Rezvov
- Jakob Kummerow
- Jeff Charles
- Justin Michaud
- Keith Winstein
- Léo Andrès (OCamlpro in the notes)
- Luke Wagner
- Manos Koukoutos
- Michael Ficarra
- Nick Fitzgerald
- Nuno Pereira
- Paolo Severini
- Petr Penzin
- Pierre Chambart (OCamlpro in the notes)
- Ryan Hunt
- Sam Clegg
- Sean Jensen-Gray
- Sergey Rubanov
- Shoaib
- Shravan Narayan
- Slava Kuzmich
- Talg
- Yuri Iozzelli
- Yury Delendik
- Zalim Bashorov
Memory control: Proposal update and Implementation report (Deepti Gandluri) slides
RH: From SM perspective, we’re open to prototyping with read-only memory and things like that. I think there are concerns about portability but if we could get something acceptable in performance in portability it would be really useful. Adding a memory type might be useful here because it might have different performance characteristics for portability.
DG: Thanks i do agree it will be useful to prototype just to get some data and then we can figure out how to move forward.
KW: Thanks for the proposal. Right now the spec prohibits any API from reducing the size of a memory but it would be nice if you were trying to map a file if the memory could be sized to the actual file you are mapping. I think it would take time to relax that in the threaded context.
DG: Gone back and forth on reducing the size of the memory but impl perspective V8 makes a lot of assumptions about not shrinking the memory and there are implications like how much memory we reserve upfront. Would be interesting to prototype but I want to be realistic about the security sensitive surface. Tried to poke at it but never successfully done it. Take it as a note and might be useful in the next section of this which is about the Impl on discord.
KW: No opinion on host imports but at a future stage it would be helpful if the imports API was not a web browser API and was done with a broad base of comfortability.
DG: I would imagine web engines would prototype and present the results of the implementation and if we decide to put it in the core spec and the wider ecosystem would benefit, it would be challenging to add to the core spec. We can walk back to the core spec after prototyping.
KW: Would be nice if a memory had a validation error if you wrote to the read-only memory.
DG: Thanks, will follow up offline.
AR: How do you spec this, would be difficult with the combination of threads. The memory model for this is nontrivial. Already the memory model is at the forefront of the current stage of research on memory. We pushed the boundaries of what was done before. I’m not entirely up to date with the literature but I think it’s outside what anyone has tried to specify so this will be challenging.
DG: I think that’s why what we’re trying to do is prototype in a tiny scaled way. Working thru the issues when threads is involved and took a break from it. But there is a lot of value in zero copy memory sharing. The goal is to just to iterate here to find the subset that is possible to implement, portable and performant. I don’t know what that subset is but I think it will be experimentation.
AR: I don’t want to discourage experimentation, very valuable, but just want to warn everyone that it might take quite some time to spec and figure this out. Might be as hard to figure out implementation issues. Doesn’t mean we shouldn’t ry, but worth noting.
DG: Appreciate the note. I don’t know if I grasp how hard but I know it will be hard.
PP: Something along these lines happened at the embedded presentation. There was something from Shin? that they were looking to get zero copy access. Think they also wanted universal pointers that would work across different memories. Just a reminder.
DG: Thanks
Chris Woods [from chat] Yup, overlap with the embedded world. Think this is an awesome idea. Would love to follow up with Deepti.
Memory control: Proposal update and Implementation report (Ryan Hunt) slides
Demo website (works in Firefox Nightly): https://bvisness.me/apps/discard/
AR: If I access it I don’t trap, it’s just 0?
RH: It’s not that after you do this the pages are no longer accessible, it’s that if you access them again you will get zeroes.
AR: Is this an atomic operation? How does it interact with other threads?
RH: Difficult because from a semantic perspective we want it to be equivalent to memory.fill which is not atomic but in terms of what the OS does, it’s fuzzy and I’m not an expert of that. Definitely not atomic of the whole range because that doesn’t seem possible.
OCamlPro [via chat]: That might work with a segault handler to handle the accesses between the two syscalls
Thomas Lively [via chat]: unless some other thread writes a non-zeros in the meantime?
Ben Visness [via chat]: That's effectively the same as racing on memory.fill - we assume that if you have data races, you might not get all zeroes at the end.
Sam Clegg [via chat]: wouldn't other threads writing non-zeros will always bring a page back into the working set.. regardless of method
DG: Thanks for all the data. Unity requested this for low memory devices. The blocker is tool support so they can compile and use it?
RH: This is the only real experiment we’ve done at this point. I would love to have Unity or other folks. And would be happy to help with others experiment. Whatever they are using, malloc or libc, would need to integrated with it.
BV: I believe the Unity employee integrated the memory discard into Emscripten’s memory allocator but we never heard back if that was useful, but it was easy to integrate at least.
Keith Winstein : Do we think modules will often want to discard regions from the interior of a linear memory, or is this something we envision will mostly be used on a suffix of the memory's current size?
RH: If anyone is here from windows, and can give us the semantics we want, would really appreciate that
KW: Re-asking questions from chat
RH: It does appear that in certain cases, that just doing the suffix at the end, with discarding the lower end can work, there are concerns about fragmentation for long running applications. The length of memory, when you were talking about shrinking, decreasing the length is hard in spidermonkey, we don’t want to change the memory length because we want to move the memory arouynd, update guard pages. So reducing the length makes it harder.
BV: Doing the discard, removing pages from the working set is really as good as shrinking memory. The only thing that matters to memory metrics like OOM killers is the impact to the working set of memory pages. Reserved memory or memory that has not been touched yet, really has no impact, though it’s more subtle on Windows. At this point I don’t think shrinking matters given how good discard it at removing memory pressure.