Hi, not sure yet about a good time slot, so I pinged you over Gmail chat. On Wednesday, October 5, 2022 at 7:30:29 AM UTC+2 [email protected] wrote:
> Hey, > > Sorry for the late reply, had some work stuff blocking my calendar. A > pair-coding session would be ideal if at all possible. Would Friday > afternoon work for you? eg. At 12 or 1 PM on Friday. > > -Aapo > > On Monday, 3 October 2022 at 12:58:58 UTC+3 Maya Armyanova wrote: > >> 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/624545ba-b1af-42c3-b2ae-fd382e5124d2n%40googlegroups.com.
