perf(ext/ffi): support Uint8Array in fast calls #15319
Conversation
|
Suggestion: Lets define a Bonus points for defining |
| @@ -32,7 +32,8 @@ fn native_arg_to_c(ty: &NativeType) -> &'static str { | |||
| NativeType::I64 => "int64_t", | |||
| NativeType::ISize => "intptr_t", | |||
| NativeType::USize => "uintptr_t", | |||
| NativeType::Pointer | NativeType::Function => "void*", | |||
| NativeType::Pointer => "struct FastApiTypedArray*", | |||
| NativeType::Function => "void*", | |||
There was a problem hiding this comment.
Should we change this to use the void(*pN)() type while we're here?
There was a problem hiding this comment.
Please elaborate why it should be such type
There was a problem hiding this comment.
Because there's no guarantee on a language level that a data pointer is valid as a function pointer.
It is so for all the envs that Deno supports, but technically they may not be the same.
There was a problem hiding this comment.
@littledivy please take a look
There was a problem hiding this comment.
Admittedly this is very rare: Embedded systems using the Harvard architecture have smaller function pointer size. Some others might also be like this but it's really not a big consideration.
There was a problem hiding this comment.
We already have a const assert for this assumption
|
Seems like the assembly for handling the buffers isn't too bad at all: trampoline:
mov rdi, qword ptr [rsi + 8]
jmp qword ptr [rip + actual@GOTPCREL] |
Closes #15218
This patch replaces the fast call path for
pointertypesfrom
uintptr_ttoUint8Arraysequence. There may beAPI changes in the future to avoid deopt in number paths.