I'll second that. It sounds like this is working as intended. Wasm has an option to use guard pages in lieu of explicit bounds checks. To do that we reserve a large, 8GB chunk of memory. The important thing is that this is marked as inaccessible and is not committed, so it does not consume physical resources. After reserving the large memory region, we change the protections on the part Wasm will actually use (16MB in your case, it looks like) so that the Wasm memory will be accessible and committed.
You can disable this behavior by passing "--no-wasm-trap-handler" to V8. On Monday, September 25, 2017 at 1:53:19 PM UTC-7, Jakob Kummerow wrote: > > What exactly is the problem? Did you observe a crash? I think you're just > seeing guard pages in action. > > Note the difference between "Reserve" and "Allocate"; your custom > ArrayBufferAllocator must distinguish these correctly. That "impossible > amount of memory" is never going to be allocated, it is just reserved in > the address space, so that accesses to it can be intercepted without > crashing the process. While the numbers do look big, the 64-bit address > space is large enough that this trick is easily possible. > > On Mon, Sep 25, 2017 at 1:03 PM, <[email protected] <javascript:>> > wrote: > >> Hello all, >> >> I have a custom impl. of V8 here (not node or chromium) and im trying to >> use the WebAssembly backend of V8. >> >> Well its all good and working fine.. but i had to manually change the v8 >> source i have here because theres some >> bad allocation policy here pushing a impossible amount of memory to be >> allocated by the custom ArrayBufferAllocator. >> >> I dont know if the problem its fixed already, but in case its not, here >> it goes: >> >> in wasm-js.cc::WebAssemblyMemory it figures 'int64_t initial' correctly >> and then calls wasm::NewArrayBuffer(...) >> >> The 'problem' here is that 'i::FLAG_wasm_guard_pages' evaluates to true >> (and my 'fix' was forcing a false here) >> >> on 'NewArrayBuffer' >> >> > enable_guard_regions = enable_guard_regions && kGuardRegionsSupported; >> (evaluated to true) >> >> (the real problem was here) -> TryAllocateBackingStore(.. >> enable_guard_regions ..); >> >> on 'TryAllocateBackingStore' >> >> if (enable_guard_regions && kGuardRegionsSupported) { >> ... >> isolate->array_buffer_allocator()->Reserve(allocation_length); <-- HERE: >> 'allocation_lenght' asks for a impossible ammount of memory number.. >> like 18 tb or 180 gb.. >> >> } else { // by forcing enable_guard_regions to false it goes here now, >> and the ammount to allocate is fine >> ... >> isolate->array_buffer_allocator()->Allocate(size); >> // here 'size' is fine.. it evaluated to 16MB in my case with a '256' >> memory number on js side >> } >> >> Note: im my custom pipeline im using the sync versions wasm::SyncCompile >> and wasm::SyncInstantiate on the C side.. not using the js api. >> I just hand back to js runtime the handle for the final instance >> >> I dont know if this was already fixed, but i tought it worth warning the >> v8-dev team so you guys can handle accordingly. >> >> >> -- >> -- >> v8-dev mailing list >> [email protected] <javascript:> >> 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 [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- -- v8-dev mailing list [email protected] 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
