Has Maya possibly returned from vacation? Or is their leave still continuing?
On Friday, 29 July 2022 at 12:08:53 UTC+3 ah...@google.com wrote: > Maya is on leave over the summer, unfortunately. > > On Fri, Jul 29, 2022 at 11:02 AM Leszek Swirski <les...@chromium.org> > wrote: > >> +Maya, you're probably the best person to answer this. >> >> On Tue, Jul 26, 2022 at 9:05 PM Aapo Alasuutari <aapo.al...@gmail.com> >> wrote: >> >>> Hello, >>> >>> I'm interested in implementing `void*` pointer support for Fast API >>> calls. My thinking was that V8's `External` objects are appropriate to >>> stand in for external `void*` pointers coming in from external code and >>> going back out, since that's what they're (presumably) meant for. >>> >>> Unfortunately this seems to be a complex endeavour, a bit more than I >>> can start hacking together directly. I'm also not sure if the `Sandboxify >>> JSExternalObject external pointer` PR will complicate this plan of mine. >>> >>> The origin of my interest is Deno FFI support, that is calling native >>> libraries from Deno JS runtime that uses the V8 engine. Recent changes to >>> the FFI have added V8 Fast API support and made the FFI a lot faster, but >>> unfortunately we're bound to using plain numbers as pointers, meaning both >>> that creating pointers is as easy as just writing a number and that (Fast >>> API compatible) pointers are limited to 53 bit numbers which will not be >>> enough for eg. pointer cryptography on ARM v8.3. >>> >>> It believe it would be preferable if Deno could use `External` objects >>> to stand for pointers but this would negate the current Fast API >>> performance benefits. Thus, `void*` pointer support for fast calls. >>> >>> >>> Any comments? Suggestions on how I might best proceed with this to >>> implement it? Or is this perhaps not a reasonable idea? >>> >>> Side note: I was sad to find that getting the pointer value out of an >>> `Local<External>` is measurably slower than getting the pointer number >>> value out of a `Local<Number>`. This is presumably due to the `External` >>> internally saving the pointer in the `ExternalMap`. The slower performance >>> is still a bit sad, from having expected `External` to be the main public >>> API meant to handle external pointers. >>> >>> -- >>> -- >>> v8-dev mailing list >>> v8-...@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+un...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-dev/a4914444-88bf-4238-828c-9ec3f2e09878n%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/v8-dev/a4914444-88bf-4238-828c-9ec3f2e09878n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> -- >> v8-dev mailing list >> v8-...@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+un...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/v8-dev/CAGRskv_o%3DdZTXdYAceSM%2BdaabpJKFYZwEFMjvzS3_8jy3e0TuQ%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/v8-dev/CAGRskv_o%3DdZTXdYAceSM%2BdaabpJKFYZwEFMjvzS3_8jy3e0TuQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- -- 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/17c3b560-e88d-41a7-b64d-d792b4021613n%40googlegroups.com.
