Feature
GC infrastructure for winch to use (refs in the value stack, stack maps, collector support).
Benefit
I was recently talking to @saulecabrera about adding exception handling support for winch. It appears that the largest obstacle is lack of gc types for allocating exception objects. This is the primary benefit motivating me for adding gc functionality at the moment, but also at some point somebody will likely want to actually add GC instruction support, and I'd like for this work to be of use to whoever that is.
Implementation
I think the first best step would be to add stack maps and refs in the value stack. I've actually been spiking on this recently and should be able to get a PR up over the weekend unless somebody thinks there is a better entry point into this work. After talking to Saul, it seems like it would be best to minimize the number of libcalls needed. From what I can tell, if we don't add any, then I'll have to implement winch logic analogous to cranelift in visitor.rs. I'm happy to do this, but from a complexity perspective we may want to weigh some libcalls. Whether the logic lives in libcalls or winch, I think it would primarily be for getting and setting globals and tables initially. Any feedback welcome, I'm sure I'm missing known obstacles.
Alternatives
I originally showed Saul an experimental branch where I was looking at adding a libcall specifically for allocating exception objects, and after talking we decided it made more sense to deal with gc more directly.
Feature
GC infrastructure for winch to use (refs in the value stack, stack maps, collector support).
Benefit
I was recently talking to @saulecabrera about adding exception handling support for winch. It appears that the largest obstacle is lack of gc types for allocating exception objects. This is the primary benefit motivating me for adding gc functionality at the moment, but also at some point somebody will likely want to actually add GC instruction support, and I'd like for this work to be of use to whoever that is.
Implementation
I think the first best step would be to add stack maps and refs in the value stack. I've actually been spiking on this recently and should be able to get a PR up over the weekend unless somebody thinks there is a better entry point into this work. After talking to Saul, it seems like it would be best to minimize the number of libcalls needed. From what I can tell, if we don't add any, then I'll have to implement winch logic analogous to cranelift in visitor.rs. I'm happy to do this, but from a complexity perspective we may want to weigh some libcalls. Whether the logic lives in libcalls or winch, I think it would primarily be for getting and setting globals and tables initially. Any feedback welcome, I'm sure I'm missing known obstacles.
Alternatives
I originally showed Saul an experimental branch where I was looking at adding a libcall specifically for allocating exception objects, and after talking we decided it made more sense to deal with gc more directly.