On Sun 24 Nov 2019 11:52, Ludovic Courtès <l...@gnu.org> writes: > A few days ago David was explaining on #guile how ‘bytevector->pointer’ > was generating too much garbage for his use case. An idea we came up > with was to embed the pointer object in the bytevector. > > The patch below does that but it leads to segfaults because I’m guessing > there’s generated bytecode somewhere that still uses the wrong offset; I > adjusted code that emits ‘pointer-ref/immediate’, what else did I > miss?
The compiler :) Bytevector literals are stored statically in the .go files, so the assembler would need to change to emit the new layout. Also, compiled access to bytevectors; see prepare-bytevector-access in (language tree-il compile-cps). > Also, since we disable internal pointers, we’d need to register an > additional displacement, and I’m not sure if this is a good idea. > > Thoughts? Honestly I would prefer not to do this. If I understand correctly, the problem is in FFI calls -- you have a bytevector and you want to pass it as a pointer. In that case the "right" optimization is to avoid the scm_tc7_pointer altogether and instead having an unboxed raw pointer. The idioms used in FFI are local enough that a compiler can do this. More broadly -- the current FFI is an interpreter but it should be a compiler. When a call happens, the code interprets the description of the ABI. Instead, pointer->function should ideally *compile* a trampoline. In an ideal world this compilation can happen ahead-of-time, when the .go file is compiled. In the short term, what about allowing bytevectors as arguments whereever a pointer is allowed? Perhaps it's bad to expand the domain of these functions but it may be the right trade-off. Andy
