Define the Perlang memory model

[perlun]

At the moment, Perlang is a garbage-collected, memory-managed (by the .NET CLR), interpreted language, but what should the long-term plans in this area be? #377 introduces an interesting concept where we start using unmanaged memory for our AsciiString backing byte arrays. This leads us to this issue: define what the memory model should look like. These are the main contenders:

• Garbage-collection, like Java, .NET, Go, Python, Ruby, JavaScript and others.
  • Pros: Easy for the programmer most of the time (until you need to think about weak references/object retention). Easy to understand for newbie and experienced programmers alike.
  • Cons: Unpredictable. GC pauses can feel "random" to the casual observer. Unsuitable for most "real-time" applications like games.
• Manual memory management, like C and C++.
  • Pros: Easy to implement in the language/runtime. Maps well to the system-level malloc/free/sbrk system calls. Predictable, deterministic performance.
  • Cons: A pain to work with for most developers. Easy to make simple mistakes which can cause serious security issues (use after free, use before malloc, buffer overruns, buffer underruns, etc). C++ with "smart", reference-counted pointer can mitigate this to a certain extent. Still, it's considered a less attractive approach because of the complexity of getting it right for the average developer.
• Implement a lifetime model, like Rust. Here is where it gets interesting.
  • Pros: Tries to balance the best of both worlds. "Automatic" handling of memory deallocation, while still remaining deterministic and predictable.
  • Cons: Steep learning curve for new developers. "Wrestling with the borrows checker" is the term being used in the Rust community.

---

Right now, I am leaning towards the latter option, perhaps doing something like:

• Use stack allocation for objects which can be statically analyzed to only be used in a given method (this is a quite common use case), or perhaps more precisely, block (remembering that blocks can be nested). Doing this will reduce the pressure on the allocator; there will be no allocation needed in fact! Just grab a piece of memory from the stack which is already there for us. Certain precautions will need to be taken to avoid using this for "too-large" objects; perhaps the limit should be 256 bytes per allocation/4096 bytes per method (combined limits) or something like that.

• Use garbage collection for anything else, but try to do it like Pony does it where garbage collection takes place when a thread in active. Need to research this more, to see how relevant this is for us if we don't go into a hardcore actor-based model like Pony does it.