Wine bug only; works OK on real Windows.[1][2] (bugs.winehq.org seems to be down)

[1] https://forum.winehq.org/viewtopic.php?t=37688

[2] https://bugs.winehq.org/show_bug.cgi?id=54979

  void *sane_realloc(void *ptr, size_t size)
  {
     if (ptr == 0) {
       return malloc(size);
     } else if (size == 0) {
       free(ptr);
       return 0;
     } else {
       return realloc(ptr, size);
     }
  }

With the above you can initialize a vector to null, with size zero, and use nothing but realloc for the entire lifetime management: growing it from zero to nonzero size allocates it, shrinking down to zero frees it.

malloc(0) doesn't necessarily return null; it can return some non-null pointer that can be passed to free. We can get such a thing if we call sane_realloc(0, 0), and can avoid that if we change the malloc line to:

   return size ? malloc(size) : 0;

The default was to reserve 4GB per connection, because each Wasm sandbox can allocate at most that, and each connection is its own sandbox.

It works fine, until it doesn't and I get users complaining this messes up almost everything slightly more complicated than Linux on bare metal: https://news.ycombinator.com/item?id=42057378

Now I do mostly the same, but reserve 256MB (or even less) per connection. It works, but it's not free.

Of course, C++ being C++, the language-level position is "it's all UB" either way (except for implicit-lifetime types), and even the proposals for trivial relocation make you go through a special function [0].

[0] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p27...

This was causing massive problems trying to concurrently read a stream over the network and start parsing it, because the realloc had trouble finding appropriately sized fragments. Once I pointed it out to the lead dev he used a different strategy and cut the load time on a multi-megabyte file by a factor of ten.

Much later on I would learn that he could have also solved the problem just by adjusting the growth factor to 1.5 instead of 2x.

Enter myself and a buddy of mine. First thing we discovered was that they were using regular java.lang.Strings for all the string manipulation, and it'd garbage collect for between 30 and 50 seconds every minute once the process got rolling. It used a positively criminal number of threads as well in our predecessor's desperate attempt to make it go faster. SO much time was spent swapping threads on CPUs and garbage collecting that almost no real work got done.

Enter the StringBuffer rotation scheme. John and I decided to use the backup GS-160 as a hub to read source data and distribute it among 16 of our floor's desktop machines as an experiment. The hub was written in C++ and did very little other than read a series of fixed-length records from a number of source files and package them up into payloads to ship over socket to the readers.

The readers gut-rehabbed the Java code and swapped out StringBuffer for String (and io for nio) to take the majority of garbage collection out of the picture.

The trick we employed was to pre-allocate a hoard of StringBuffers with a minimum storage size and put them in a checkin/checkout "repository" where the process could ask for N buffers (generally one per string column) and it'd get a bunch of randomly selected ones from the repo. They'd get used and checked back in dirty. Any buffer that was over a "terminal length" when it was checked in would be discarded and a new buffer would be added in its place.

We poked and prodded and when we were finally happy with it, we were down to one garbage collection every 10 minutes on each server. The final build was cut from 30 days to 2.8 and we got allocated a permanent "beowulf cluster" to run our database build.

However, system calls also have overhead (thanks Meltdown/Spectre mitigations), and you might not come ahead by avoiding memory copies.

(including the page tables)