On Wed, Jan 15, 2020 at 5:05 PM Immanuel Haffner <haffner.imman...@gmail.com> wrote:
> Hi Clemens, > > Thanks for your answer. I already had that thought. But copying data is > just not an option. > > To make my scenario more concrete: > I habe data in main memory, easily tens or hundreds of gigabytes. Programs > fly in requiring to access the data. Some programs are short-lived, some > will take a long time to compute. Some programs are executed only one, some > are executed repeatedly. So I will have to JIT compile many programs to > WASM modules. Copying the data into the memory of each module would totally > kill performance. > > Another idea that comes to my mind is to create a single WASM memory > object and implement a designated allocator to allocate memory for host > objects in that WASM memory. Then I could import this memory object into > the modules... Would that be possible? How would the guard pages affect > this approach? (I am thinking of jemalloc on WASM memory.) > Sharing wasm memory across modules works generally. You could have one module that provides some kind of library to the other programs for allocating and deallocating memory, and accessing shared state. You would have to trust all programs though not to mess with the shared memory. A memory bug in one program could easily cause failures in others. Also, most programs use parts of the memory for their stack and for global variables. You have to make sure then to malloc all of this memory so there are no conflicts between programs. If you don't mind patching v8 a bit for your work, you could of course add a way to make a wasm instance use a given array buffer for its memory. Things like growing the memory would not work then, and you either have to enable explicit bounds checks (by disabling trap handlers, --no-wasm-trap-handler flag), or you need to trust your programs never to access memory out of bounds. These might be viable options if a) this is a research project / prototype, or b) you control / trust the programs you execute. Cheers, Clemens > I understand that the problem I am proposing is somewhat in contradiction > with the WebAssembly idea of sandboxed modules. Anyways, I believe solving > this would make WebAssembly make an attractive choice for JIT compiling > general purpose languages. > > Regards, > Immanuel > > -- > -- > v8-dev mailing list > v8-dev@googlegroups.com > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to v8-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/2bfba5a2-91d1-400f-a3e6-89e152a238de%40googlegroups.com > . > -- -- v8-dev mailing list v8-dev@googlegroups.com http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CAGO%3DqhDiY7j0nqeknY3OcuDE-6rrJYxHNYsJZMGDpDsMmXXm_w%40mail.gmail.com.
