Re: TypedArrays: 1. Supported list of OSes can be found here: https://source.chromium.org/chromium/chromium/src/+/main:v8/include/v8config.h;l=65;drc=56816d76c121c8dd5b406dc6019350eee05f4abd, the platforms are basically the subfolders of this one: https://source.chromium.org/chromium/chromium/src/+/main:v8/src/codegen/ 2. I think only options b) or c) (copying or owning) are viable and safe, tbh. Option c) can be done as "pre-allocating" the TypedArray backing store before doing the call.
Re: External support - I see, I got confused that the External* is itself the C++ pointer we care about. Well, then similar to before, you could use a void* -> kExternalObject (or similar, which would be a new value in the ` CTypeInfo <https://source.chromium.org/chromium/chromium/src/+/main:v8/include/v8-fast-api-calls.h;drc=ca79bd5301566d1a3fc573c6e6858b5880c00fbd;bpv=1;bpt=1;l=238?q=v8-fast-api&ss=chromium%2Fchromium%2Fsrc&gsn=CTypeInfo&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dv8%2Finclude%2Fv8-fast-api-calls.h%23CTypeInfo%253Av8%2523c%2523e_ls0qYyK2W&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dv8%2Finclude%2Fv8-fast-api-calls.h%23dMPvmiRrvw3l_OsAMR9ohZmSdnWRW8R-_2NiNbbD7iY&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dv8%2Finclude%2Fv8-fast-api-calls.h%236wxW2bJwcslyangF4orYB2B15hGRi1fZ1AItHcr1mzg&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dv8%2Finclude%2Fv8-fast-api-calls.h%23mNHELKqnuizIokdjlQhDQwpDB8ko3WdwYlSnpqC7vTQ>::Type` enum) mapping in the public header, then handle this kExternalObject similar to kV8Value. From the machine point of view, it's still only a machine word-sized pointer. And then we'll need tests that use it and some code in Turbofan to read out the External::Value out of the wrapper object and pass it as the void* param. Maybe we can setup a chat or pair-coding session in the coming days, I'm based in CET timezone. Re: ops - thanks for the explanation, sounds really cool indeed. Please let me know how can I further support you! Maya On Friday, September 30, 2022 at 2:20:10 PM UTC+2 [email protected] wrote: > Re: Returning TypedArrays > 1. Yeah, this definitely needs to be carefully considered. Is there any > easy listing of supported V8 compilation targets? A simple preliminary > study would be to just check good old Godbolt compiler against the list :) > 2. This is indeed fraught with both potential user errors and plain bad > ideas. An example of what I've already implemented for Deno FFI for normal > binding functions is for users to get an ArrayBuffer out of a pointer with > a given byte length. This is useful, or even necessary, for some C APIs > where mutating memory through a pointer is needed. These are created with a > BackingStore using a noop deleter callback, so effectively the BackingStore > is not taking ownership of the data, just referencing it. However, lifetime > becomes an issue as of course the BackingStore does not know how long the > pointer is valid. Thus, a user error may lead to a use-after-free error. I > guess that's FFI for you. Generally though, from a V8 perspective, you > should be able to trust the fast call to return a proper length with the > pointer to be turned into a TypedArray. The only real issue, I think, is > how to deal with the three different options of: > a) Reference TypedArray: V8 does not control the lifetime (dangerous since > now JS-side user error creates use-after-free) > b) Copied TypedArray: V8 should copy byteLength bytes from the pointer. > c) Owned TypedArray: The pointer is actually already owned by V8, ie. > somehow a fast call is returning a pointer it received from V8 in the first > place, or (if such an API is provided in the future) the fast call > allocated a buffer into V8 heap and is now returning it as a TypedArray. > The return type CType might be used to tell V8 what it should do with such > a TypedArray but it's still fraught with danger. No easy answers here. > > Re: External support > I think you might've misunderstood my meaning with passing External > pointers as parameters. I wasn't referring to an External* but instead the > void* that one would receive by calling the Local<External>::Value() > method. My original thinking was that lowered V8 code might even turn > Local<External> internally into the void* though the Value() method, but > thinking on it now it may not makes sense (how to return to the > Local<External> from the void*? So not a good idea.). So, in the end it > would be that a fast call with a declared void* parameter would expect to > find a Local<External> in that parameter slot, and will call the fast call > with the Local<External>::Value() return value in that parameter slot. So, > the C++ side will never even see the Local<External> but will instead > simply receive a pointer to whatever the External is pointing to. This is > why I expected this to be a bit harder than just working with the public > API file, as I expect this will need at least some work on the lowering > code. > > Re: ops layer > The ops layer is how Deno binds the JS world to native code. Ops are > called from JS through eg. *Deno.core.ops.op_print("foo")*. This function > is a V8 FunctionTemplate instance, which will then call into the Rust code > that actually implements Deno's own console printing. And as said, each > op's V8 FunctionTemplate binding code is generated automatically and if the > parameters and return value of the Rust function match what Fast API is > capable of, the op FunctionTemplate will be created with a fast call. > > -Aapo > > On Friday, 30 September 2022 at 13:56:08 UTC+3 Maya Armyanova wrote: > >> Hi again, >> >> Regarding the void pointers, idea #2 sounds good to me too. I guess >> there's no really need to pre-allocate anything. >> >> Regarding returning TypedArrays as a pair of pointers - this sounds like >> an interesting idea indeed. Still, two questions come to my mind: >> 1) this seems really platform specific and we should really carefully >> study all calling conventions we care about (and we have quite a few); >> 2) "considerations of ownership, lifetime, copying, memory management" - >> yeah, this is what bothers me too. The fast API isn't really so much about >> safety, but it shouldn't open any obvious security holes. And returning a >> random address from C++ and providing that as a TypedArray elements store >> seems pretty fishy to me. I can imagine all kinds of dangers such as >> out-of-bounds reads or writes. >> >> Regarding External - small correction to what I wrote above, we can use a >> Local<External>, similar to Local<Value>. And a possible reason why it is >> slow (thanks to verwaest@) is that External is a full-blown JSObject, >> having its own elements and property backing store, which is unused for C++ >> objects (which it is supposed to represent). >> >> Re: Strings passed around as Values - wow, now this seems risky indeed. >> The worst we could stumble upon is again unexpected memory writes. Not sure >> how possible in reality that is, but I'll need to ping someone more >> familiar with security concerns. >> >> A noob question - what is the Deno ops layer and what would an engineer >> use it for? >> >> Regarding overload resolution with null parameters in the middle - yeah, >> the purpose of not supporting the full overload resolution logic that Web >> APIs have was to keep this code simpler. Otherwise at runtime time we'll >> need to repeat much of what Blink already does, possibly making the fast >> dispatch slower. Regarding the JSObject shapes, not sure how relevant that >> is, but we had an idea to provide the embedder with means of enumerating >> their C++ types and representing their hierarchy in V8 using those assigned >> numerical IDs. This would be super useful for Web APIs such as accessing >> e.g. Node.nodeType from various successors of Node (such as Div). >> >> Regarding implementing External support - again a correction, you could >> have a Local<External> on the C++ side. And you could already try passing >> the External* or Local<External> as an argument and use the (obsolete) >> kApiObject parameter type. Add a mapping here >> https://source.chromium.org/chromium/chromium/src/+/main:v8/include/v8-fast-api-calls.h;l=666;drc=ca79bd5301566d1a3fc573c6e6858b5880c00fbd >> >> from Local<External> to kApiObject, the low level machinery for it is still >> there. And how the C++ function takes the argument - as a raw pointer or as >> a Local - is actually the same for the generated code that calls it, so >> it's your call. If it works (or it doesn't), please feel free to upload a >> CL on Gerrit, happy to take a look. >> >> Good luck, >> Maya >> >> On Friday, September 30, 2022 at 12:01:12 PM UTC+2 [email protected] >> wrote: >> >>> Hey, >>> >>> Thank you for getting back to me! >>> >>> I'm definitely interested in implementing Externals for C callbacks both >>> as parameters and as returns values. Returning void pointers should prove >>> to be more difficult I guess. I can see two ways to go about it: >>> 1. Take the same route as you mention for returning TypedArrays, where >>> V8 will allocate a placeholder before calling the callback. >>> 2. Simply have the C callback return the pointer and have V8 do the >>> allocation after calling it. I presume this should be doable since the >>> return value CType can (or perhaps "should") be trusted to speak the truth, >>> and returning a pointer does not cause any issues calling convention wise. >>> >>> My personal preference is definitely on #2, as it feels more "natural" >>> and contains less indirection. It also has the slight benefit of not doing >>> any unnecessary allocations for the External when the fast callback signals >>> a need to deopt using the fallback flag. >>> >>> I wonder if #2 could be used to likewise implement TypedArray returning? >>> I can't exactly remember the System V ABI for C++ structures but I seem to >>> recall that a structure with a size of up two two pointers worth can be >>> returned through RAX and an extra register (that is, as long as the class >>> does not have an non-trivial copy constructors or destructor). Other ABIs >>> might of course differ on that. Still, if it happened to be so that all >>> ABIs allowed returning two pointers, it would mean that a C callback could >>> return the same TypedArray struct that is used to pass them in as >>> parameters. (I'm skipping considerations of ownership, lifetime, copying, >>> memory management and all that because it gets hard and ruins my idea >>> pretty well :D ) >>> >>> On Strings: It turns out that as long as one keeps a pointer to the >>> Isolate somewhere, it's already possible to support String parameters in >>> fast calls, at least to a limited and possibly unstable degree. See this PR >>> of mine: https://github.com/denoland/deno/pull/16014 >>> Essentially, if a parameter is declared as v8::Value then it will >>> happily accept a String as well, and with the Isolate pointer it is then >>> possible to write the string data out. I'm unsure of the safety of this, I >>> expect it should panic on roped strings as V8 flattens them but so far I've >>> not seen clear evidence of that happening. >>> >>> I personally think that a limited C string return only -kind of string >>> support would not be a good idea. As an example, I expect that the Chrome / >>> Blink team would find good use for returning of UTF8 strings in atob / btoa >>> and TextDecoder APIs. (And so would Deno.) Again here I ponder on the >>> possibility of the option #2 above. >>> >>> About Deno's interest in Fast API in general: I'm not part of the Deno >>> team, and am only contributing to the FFI and a little bit on the core ops >>> (JS <-> Rust binding) layer so I cannot truly speak for what the team >>> considers important and am just speaking for myself. That being said: >>> 1. Deno's FFI API relies heavily on Fast API. Every foreign library's >>> symbol (C function) that a user wants to use will by default use the Fast >>> API. Only symbols that call back into V8 need to / should opt out of this >>> using a "callback" boolean option. >>> Adding more supported types to Fast API directly adds to wider and >>> better support for Deno FFI. As an example, currently returning of 64 bit >>> integers (eg. pointers) is done via a TypedArray out pointer, where the >>> pointer is written into. If returning of External objects was possible, >>> this out pointer system and its (slight) performance overhead could be >>> removed. (And most importantly, numbers-as-pointers insecurity could be >>> eliminated.) >>> Returning of C strings would allow Deno FFI to have "native" support of >>> those (currently C string extraction is done via a separate method). >>> >>> 2. Deno's ops layer has recently moved to using Fast API by default >>> where possible. Deno's binding functions are written as normal Rust >>> functions and an ops macro takes care of writing the binding logic to V8's >>> FunctionTemplate. >>> Due to the near-universality of the ops macro, any Fast API binding >>> logic needs to only be written once and the macro will take care of taking >>> setting up the bindings for all ops that are bindable. Thus, here even more >>> than with FFI, having more supported types leads near-automatically to >>> faster binding layer in Deno, which is very much of interest to the Deno >>> team. >>> Some examples: >>> * FFI might not benefit from Strings as parameters that much, since >>> foreign APIs would only expect C strings. Deno ops however very much would >>> like to get arbitrary (UTF8) strings in fast calls. They would also love to >>> return arbitrary UTF8 strings. >>> * FFI only cares about returning pointers in some form, External being >>> the most logical. Deno ops would very much want to return TypedArrays of >>> varying sizes, and they would not mind being explicit about memory >>> management either. >>> * ops have cases where eg. a String or TypedArray parameter might be >>> optional. Overloads are already supported to a degree, but eg. null >>> parameters in the middle currently are not supported directly (except as >>> v8::Values which I'm not sure if it would ruin the "better typed" overload >>> matching) >>> * (Completely impossible stretch goal): Some ops take objects of some >>> given shape. If V8 were to match its JS object shapes to a declared >>> parameter struct shape, now that would be impossibly cool. Also, probably >>> too hard to feasibly do but a man can dream. >>> >>> >>> This has become a massive, meandering writeup. Sorry about that. >>> >>> Back onto topic: If you can give me some pointers on where I should look >>> to add the External<JSExternalObject> stuff for, I would much appreciate >>> it. I would personally also prefer to write the code such that the C >>> callback receives not the v8::External object but is directly called with >>> the pointer that the External represents. This I expect to require some >>> changes in the lowering code. >>> >>> Thank you for your time >>> -Aapo Alasuutari >>> >>> On Friday, 30 September 2022 at 11:23:56 UTC+3 [email protected] >>> wrote: >>> >>>> Hi, >>>> >>>> First of all I'm really sorry for the late reply, I didn't see Leszek's >>>> ping in time. >>>> >>>> External sounds like the right type to represent embedder pointers, >>>> though the poor performance you report sounds unfortunate. Tbh I'm not >>>> aware of particular efforts to optimize it, but it might be indeed due to >>>> the ExternalMap. I'll check with colleagues if it's possible to do >>>> something about the performance there. >>>> >>>> On the main topic, adding C callbacks that accept an argument of type >>>> External<JSExternalObject >>>> <https://source.chromium.org/chromium/chromium/src/+/main:v8/src/objects/js-objects.h;drc=ca79bd5301566d1a3fc573c6e6858b5880c00fbd;bpv=1;bpt=1;l=911?gsn=JSExternalObject&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dv8%2Fsrc%2Fobjects%2Fjs-objects.h%23JSExternalObject%253Ainternal%253Av8%2523c%2523iz6AV1GPx3E&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dv8%2Fsrc%2Fobjects%2Fjs-objects.h%23JSExternalObject%253Ainternal%253Av8%2523c%2523bNyn58S6iE1&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dv8%2Fsrc%2Fobjects%2Fjs-objects.h%23E1nu-FvBjuQ-EDx8Ny1DO3ZL7UJtt6bOOeiU34UFYGw&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2Fandroid-Debug%2Fgen%2Fv8%2Ftorque-generated%2Fclass-forward-declarations.h%23oOxlJQnIiQ9TdjrwzIe-NzNBbjuKOvOptxzBUUoilOc&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2Fandroid-Debug%2Fgen%2Fv8%2Ftorque-generated%2Fsrc%2Fobjects%2Fjs-objects-tq.inc%23L9uwfd2l6uOWvbRRILcxKp1VYllIsCCFPIecleuaEFI&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dv8%2Fsrc%2Fheap%2Fobjects-visiting.h%23TyseKlOYyb_hrIxmiwvcWeGQvP1INehKCer2kV7xG6o&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2Fchromeos-Debug%2Fgen%2Fv8%2Ftorque-generated%2Fclass-forward-declarations.h%23-xwKU2vBSmUrnUm0jR5GI1mRjxJU6CM4EWCILgXHArg&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2Fchromeos-Debug%2Fgen%2Fv8%2Ftorque-generated%2Fsrc%2Fobjects%2Fjs-objects-tq.inc%233_drfRrSdKh0O1Osknb0zTSBaGNV_S6BOBULYV3JPWM&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2Ffuchsia-Debug%2Fgen%2Fv8%2Ftorque-generated%2Fclass-forward-declarations.h%234v0WVozoJqd2EihNGkWvPiA8BoPsJcdwXuoyVp6QHOQ&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2Ffuchsia-Debug%2Fgen%2Fv8%2Ftorque-generated%2Fsrc%2Fobjects%2Fjs-objects-tq.inc%23LSy3_Kz2Yjawt37W-b83WmwOsNDUY4ajMD0DAb7V3Mc&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2FDebug%2Fgen%2Fv8%2Ftorque-generated%2Fclass-forward-declarations.h%23mTH4BKG-IJiVtR9UIw5dWrwbrfkz9qT70rqpwU4XjrU&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2FDebug%2Fgen%2Fv8%2Ftorque-generated%2Fsrc%2Fobjects%2Fjs-objects-tq.inc%23whuyQbV2vlE-tTFI1uVnQfjP17lKMmgcfoUlNVo-Klw&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2Fmac-Debug%2Fgen%2Fv8%2Ftorque-generated%2Fclass-forward-declarations.h%23GzTsTV0SjMocKlp1gFc9rdY5cM8CLb1snxpk-K_Yl6w&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2Fmac-Debug%2Fgen%2Fv8%2Ftorque-generated%2Fsrc%2Fobjects%2Fjs-objects-tq.inc%23e8ogLQjp7_4HdRE3K0x5oqhCsc1cPbcQrRxJ93YsGgY&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2Fwebview-Debug%2Fclang_x86_v8_arm%2Fgen%2Fv8%2Ftorque-generated%2Fclass-forward-declarations.h%23eCSrpBoyJxJqKLLRwerXtYRgNRCFPzhqMlFvXB1GgXk&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2Fwebview-Debug%2Fclang_x86_v8_arm%2Fgen%2Fv8%2Ftorque-generated%2Fsrc%2Fobjects%2Fjs-objects-tq.inc%23zx7jBWmo0iWo0ZDZ_UwWDKwgXrTwOQ0CKrx6zw1BU6c&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2Fwin-Debug%2Fgen%2Fv8%2Ftorque-generated%2Fclass-forward-declarations.h%23GSrIGaBEY2iOQfmCfE72vSRo9s9ew9qMP3oJBgobGP8&gs=kythe%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%3Flang%3Dc%252B%252B%3Fpath%3Dout%2Fwin-Debug%2Fgen%2Fv8%2Ftorque-generated%2Fsrc%2Fobjects%2Fjs-objects-tq.inc%23qHEyn9vHXkb7XJTCTYp5eFzZgB9YbJdsNIcS6VDvHxw>> >>>> >>>> should be doable, given that memory wise External has the same >>>> representation as v8::Value (which we support to pass regular >>>> v8::Object's). It should mostly be an addition to the public interface >>>> file, which I can guide you into implementing, if you're interested. >>>> >>>> Regarding the other two points: >>>> - Strings - we decided for now to leave them out of the API, due to >>>> the large number of string types in V8, which would make the >>>> implementation >>>> annoyingly complex. We talked about possibly adding limited support for >>>> return string types only, as the C++ -> JS direction would need support >>>> only for plain C strings. Still, I don't have any particular plan to >>>> implement it in the near future, but would be happy to support you if it's >>>> an important feature for Deno. >>>> - Returning TypedArrays - this is again somewhat cumbersome, as the >>>> TypedArray object would need to be allocated as a placeholder from the >>>> generated code before calling out to the C++ callback, as the callback >>>> itself is not allowed to allocate. It should be generally doable, but we >>>> didn't have a use case until now. >>>> >>>> Hope this helps, will let you know once I learn more about v8::External >>>> performance. >>>> >>>> All the best, >>>> Maya >>>> >>>> On Friday, September 30, 2022 at 7:36:21 AM UTC+2 [email protected] >>>> wrote: >>>> >>>>> Still hoping to get some guidance with this. >>>>> >>>>> I'm also interested in support, even if limited, for string value >>>>> parameters (or even return values) and returning of TypedArray buffers. >>>>> Though, I expect those to be much harder to implement than returning >>>>> External objects for void pointers. I guess a somewhat related option is >>>>> to >>>>> return external pointers as zero-sized TypedArrays / ArrayBuffers, but >>>>> that >>>>> sounds quite wrong compared to External objects. >>>>> >>>>> On Friday, 23 September 2022 at 15:15:10 UTC+3 Aapo Alasuutari wrote: >>>>> >>>>>> I presume Maya might now be back be at the office? >>>>>> >>>>>> Would it be possible to get some guidance regarding implementing void >>>>>> pointer support, either here on Groups or possibly by organizing an >>>>>> online >>>>>> meeting of some sort? >>>>>> >>>>>> -Aapo >>>>>> >>>>>> On Tuesday, 23 August 2022 at 11:32:30 UTC+3 [email protected] >>>>>> wrote: >>>>>> >>>>>>> Hi, yes, Maya is out until mid-september. >>>>>>> Cheers, Camillo >>>>>>> >>>>>>> On Tue, 23 Aug 2022 at 07:07, Aapo Alasuutari <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Has Maya possibly returned from vacation? Or is their leave still >>>>>>>> continuing? >>>>>>>> >>>>>>>> On Friday, 29 July 2022 at 12:08:53 UTC+3 [email protected] wrote: >>>>>>>> >>>>>>>>> Maya is on leave over the summer, unfortunately. >>>>>>>>> >>>>>>>>> On Fri, Jul 29, 2022 at 11:02 AM Leszek Swirski < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> +Maya, you're probably the best person to answer this. >>>>>>>>>> >>>>>>>>>> On Tue, Jul 26, 2022 at 9:05 PM Aapo Alasuutari < >>>>>>>>>> [email protected]> 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 >>>>>>>>>>> [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]. >>>>>>>>>>> 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 >>>>>>>>>> [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]. >>>>>>>>>> >>>>>>>>> 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 >>>>>>>> [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]. >>>>>>>> >>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/v8-dev/17c3b560-e88d-41a7-b64d-d792b4021613n%40googlegroups.com >>>>>>>> >>>>>>>> <https://groups.google.com/d/msgid/v8-dev/17c3b560-e88d-41a7-b64d-d792b4021613n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> Camillo Bruni | Software Engineer, V8 | Google Germany GmbH | >>>>>>> Erika-Mann >>>>>>> Str. 33, 80636 München >>>>>>> >>>>>>> Registergericht und -nummer: Hamburg, HRB 86891 | Sitz der >>>>>>> Gesellschaft: Hamburg | Geschäftsführer: Paul Manicle, Halimah >>>>>>> DeLaine Prado >>>>>>> >>>>>>> Diese E-Mail ist vertraulich. Falls Ssie diese fälschlicherweise >>>>>>> erhalten haben sollten, leiten Sie diese bitte nicht an jemand anderes >>>>>>> weiter, löschen Sie alle Kopien und Anhänge davon und lassen Sie mich >>>>>>> bitte >>>>>>> wissen, dass die E-Mail an die falsche Person gesendet wurde. This >>>>>>> e-mail is confidential. If you received this communication by mistake, >>>>>>> please don't forward it to anyone else, please erase all copies and >>>>>>> attachments, and please let me know that it has gone to the wrong >>>>>>> person. >>>>>>> >>>>>> -- -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/ea28f977-996b-446f-9b2a-b06987480aecn%40googlegroups.com.
