2 ms·
Interesting, thanks for the details! WasmGC would be the best solution here, yeah, then the VM handles pointers for you. Otherwise, I could look into the Spil
by azakai 2y ago
Interesting, thanks for the details!
WasmGC would be the best solution here, yeah, then the VM handles pointers for you.
Otherwise, I could look into the SpillPointers issue for you if you want - optimizations should not remove GC pointers, so that sounds like a bug. If so feel free to file an issue with a testcase. (But WasmGC would be best, avoiding all that.)
- disentanglement 2y agoAs far as I know, optimization levels higher than -O0 work fine with SpillPointers. But at least in a cursory first look I had a while ago, the optimizations made things slower overall. I guess they might lead actually to more "moving pointers in and out of the heap" since the SpillPointers pass is done at the very end. But this should all be investigated more thoroughly.
- jackdaniel 2y agoHey! Thanks for the offer and thanks for the correction. I've revisited relevant threads and it seems that it is indeed -O0 because things are slower with higher optimization levels (I must have misremembered). Relevant links: https://gitlab.com/embeddable-common-lisp/ecl/-/merge_requests/331/diffs https://gitlab.com/embeddable-common-lisp/ecl/-/merge_reques... https://github.com/ivmai/bdwgc/issues/650 https://github.com/ivmai/bdwgc/issues/650 Most notably an entry in the INSTALL file: ``` the optimization level -O0 is used because higher optimization levels seem to interfere with the binaryen options needed to get the garbage collector to work correctly and tend slow down the program (might be worth experimenting with the optimization options) ```