Bizhawk never would hit this because it only ever runs waterboxes in one host thread, but an application that spun up many threads and ran waterboxes in each would leak 32 bytes of heap for each native thread destroyed, which is super duper not really meaningful at all
Waterbox guest code now runs on a stack inside the guest memory space. This removes some potential opportunities for nondeterminism and makes future porting of libco-enabled cores easier.
This replaces the old managed one. The only direct effect of this is to fix some hard to reproduce crashes in bsnes.
In the long run, we'll use this new code to help build more waterbox features.
nattthebear