On Tuesday, September 26, 2017 at 10:38:35 AM UTC-7, [email protected]
wrote:
>
> Alright Eric. Thanks (Also Thanks Jacob)
>
> Good to know this is not a bug. I didnt know if it were a issue so in any
> case, i decided to report in case it was something.
>
> The number passed looks a lot like one that would come from an undefined
> int, or something like int::max (it was much more than 8 GB in my case, but
> im not using the HEAD, so..).
>
> About the trap handler, i turn it on explicitly with
> '--wasm_trap_handler', and 'Reserve()' never got called before, and when i
> implemented, i was expecting that Reserve would ask me
> for a chunk of memory it would use later, so for start i've just
> delivered, like i would with Alloc, but in this case TCMalloc terminated
> the program with no memory, giving the size being asked.
>
> Giving the size being asked for was so big, i've assumed it was not right.
>
> But anyway, for what you are saying, v8 will first call Reserve and than
> will subsequently call Alloc when it really need the memory pages right?
> Thats a fine behavior to me.. For me Reserve 'social contract' (giving you
> have to hand back a buffer) would be that v8 want a larger chunk, where it
> would
> take care of managing this chunk, while Alloc is heap it would need right
> away, and where you should give it or die if theres not enough memory.
>
Reserve is there to get a large region of memory that we know will not be
used by anything else and that any attempts to access it will trigger a
segfault. V8 later uses SetProtection on a portion of the reserved memory
to make it so that it is accessible. This accessible region becomes the
Wasm memory.
We do this so that we can avoid generating code for bounds checks. Normally
for a Wasm instruction like
(i32.load base offset)
we would do something like:
if (base + offset >= WASM_MEMORY_SIZE) {
throw WasmOutOfBoundsException;
} else {
return *((int32_t*)(base + offset));
}
Instead, we can generate just:
return *((int32_t*)(base + offset));
We know that the any out of bounds access will land in the reservation that
we haven't marked as accessible (also called the guard region). We catch
accesses in the guard region with a signal handler and the signal handler
knows how to throw the right exception.
>
> Giving i tought the same dillema was true to Reserve behaviour (alloc this
> or die), i guessed it was impossible for v8 to being asked me for that
> ammount seriously..
> this got to be some undefined int somewhere :)
>
> Anyway.. the trap handler will trigger when the wasm code try to access an
> out of bounds address? giving the source comes from C code, this is a very
> handy feature..
>
> So for instance, in this case if i hand a initial ammount in Reserve()
> giving i can expect v8 to call Alloc() later for the real deal, i can just
> hand it back the heap i've reserved before
> with the right offset while the buffer has enough size?
>
I'd recommend taking a look at the ArrayBufferAllocator included in
V8:
https://cs.chromium.org/chromium/src/v8/src/api.cc?q=ArrayBufferAllocator&sq=package:chromium&l=478
There's also a simpler one that calls the underlying OS APIs directly
at
https://cs.chromium.org/chromium/src/gin/array_buffer.cc?q=gin+ArrayBufferAllocator&sq=package:chromium&l=35
Hope this helps!
-Eric
>
> Thanks Jacob and Eric.
>
--
--
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.
