Regional-level memory management

Question

I am developing a high-level language, and I want it to have C ++ speed (it will use LLVM), but be safe and high level like C #. Garbage collection is slow, and new / delete is unsafe. I decided to try using “region-based memory management” (there are several articles on the Internet about this, mainly for functional languages). The only “useful” language using it is Cyclone, but it also has GC. In principle, objects are allocated in the lexical stack and freed when the block is closed. Objects can only link to other objects in the same region or higher to avoid dangling links. To make this more flexible, I added parallel areas that can be moved up and down the stack and saved through loops. The type system will be able to verify the assignment in most cases, but in some places small checks of runtimes will be required.

Example:

region(A) { Foo@A x=new Foo(); //x is deleted when this region closes. region(B,C) while(xY) { Bar@B n=new Bar(); nD=x; //OK, n is in lower region than x. //xD=n; would cause error: x is in higher region than nnDoSomething(); Bar@C m=new Bar(); //mD=n; would cause error: m and n are parallel. if(mY) retain(C); //On the next iteration, m is retained. } } 

Does this seem practical? Do I need to add non-vocabulary-linked counting regions? Should I add weak variables that can refer to any object, but with a check to delete the region? Can you come up with any algorithms that are difficult to use with this system or that will leak?

Answer 1

I would dissuade you from trying the regions. The problem is that to ensure the security of the regions you need a very complex type system. I am sure that you looked at the documents of Tofte and Talpin, and you have an idea of ​​the difficulties associated with this. Even if you succeed in the regions, the likelihood that your program will require life, the life of which the program is, is that this region, at least, should be collected from garbage. (This is why Cyclone has areas and GC.)

Since you are just starting out, I would advise you to go with garbage collection. Modern garbage collectors can be made pretty quickly without much effort. The main problem is to allocate from adjacent free space so that the distribution is fast. This helps to target AMD64 or another machine with spare registers so that you can use the hardware register as a pointer to the location.

There are many good ideas for adaptation; One of the easiest to implement is a page-based collector, such as Joel Bartlett's copy picker, where the idea is that you only select from completely blank pages.

If you want to learn about existing garbage collectors, Lua has a rather complicated incremental garbage collector (so there are no visible pause times) and the implementation is only 700 lines. It is fast enough to be used in many games where performance is important.

Answer 2

If I were to use a region-based memory management language, I would probably read a language-independent structure to display the region . However, some time has passed since I studied this material, and I am sure that the state of affairs has advanced, even if I knew what the current state is.

Answer 3

Well, you have to go learn apple memory management. It has release pools and zones that are undoubtedly very similar to what you are doing here.

I will not comment on the remarks "GC is slow",

Answer 4

You can start with the Tofte and Talpin documents regarding regional-based memory management.

Answer 5

How to return a dynamically created object? Who will “own” it and be responsible for freeing memory?

Refcounting or GC are so common because they are almost always the best choice. Garbage collectors can be very effective.