How autofree works

[medvednikov]

Due to many requests, I'll be writing down the principles of how autofree works. It will give a more transparent view into one of V's memory management models and will make it easier to contribute to the autofree engine, which is still work in progress.

Autofree is one of 4 ways to handle memory in V. The default one is a tracing GC, there's arena allocation with -prealloc, and manual memory management via -gc none.

There's a demo video available. Building the Ved editor with autofree and running it on an 8MB text file with 0 leaks:
https://www.youtube.com/watch?v=gmB8ea8uLsM

When I started working on V, I was very anti-GC, expecting them to be slow and use a lot more RAM. I integrated a GC just for a test, and was surprised at how well it worked with V, a very minimal language, that avoids doing unnecessary allocations in the first place by using value types, string buffers, promoting a simple abstraction-free code style. V's standard library doesn't use the GC, so turning it off for you application is not a problem (no need to use a different version of stdlib etc).

What started as a test and a temporary way to allow developers to write leak free programs, became the stable and well working default option. Autofree in fact performed a bit worse than the default GC. The reasons will be explained in this article.

Other things in the compiler were prioritized, that's why autofree still isn't finished yet. But it is important, and it will be finished. Very often using a GC is simply not an option. For examples in drivers and kernels. In fact, our Vinix kernel uses autofree.
Our goal is to make V very flexible and configurable, that's why we provide multiple ways to manage memory.

As the home page explains, autofree frees the variables that the compiler knows it can safely free. For all the remaining cases, the GC is used with an option to use manual memory management (in the future the compiler will point out the variables it can't free if -gc none is used).

The amount of such variables can vary depending on the code. It should be about 10% on average. In the mentioned Ved demo, 0% of variables are unhandled by autofree.

Let's go through what autofree can handle and what it does.

1. Simple out of scope variables.

If a variable results in an allocation, and this allocation is not used anywhere else, the variable is freed at the end of the block it was created in (i.e. the variable goes out of scope):

fn foo() {
	s1 := 'hello'
	s2 := 'world'
	s := s1 + ' ' + s2 // string concatenation results in a heap allocation
	println(s)

	foo := &Foo{} // struct allocated on heap
	foo.bar()

	s.free() // inserted by autofree
	foo.free() // inserted by autofree
}

fn main() {
	foo()
}

In this example I didn't use s := 'hello ' + 'world', because V's optimizer will simplify it to s := 'hello world', and simple string literals don't result in an allocation.

2. Allocated strings are cloned on assignments.

To ensure that string copies do not point to freed memory, they are always cloned. This is an expensive O(n) operation, and is the main reason autofree can be slower than V's default GC or manual management. It can be optimized by doing copy on write and more analysis by the compiler.

fn do_stuff(s string) {}

fn foo() {
	s1 := 'hello'
	s2 := 'world'
	s := s1 + ' ' + s2
	str_copy := s
	do_stuff(str_copy)
}

This results in:

fn foo() {
	s1 := 'hello'
	s2 := 'world'
	s := s1 + ' ' + s2
	str_copy := s.clone() // inserted by autofree
	do_stuff(str_copy)
}

This is only about strings, not arrays. Note that V forces cloning arrays on assignment, even without autofree enabled:

a.v:30:4: error: use `array2 := array1.clone()` instead of `array2 := array1` (or use `unsafe`)
   28 |
   29 |     a := [1,2,3]
   30 |     b := a
      |       ~~
   31 | }

more to come soon

[MatejMagat305]

(I do not know whether I can, but I have small note)
note:
on the one thread it is true (GC is better), but on multicore is better autofree (at least some case), because GC limit to 1.2 cores ... maybe only in some case
but Vlang is gratefull language ...!

[ArtemkaKun]

We can also try to use/implement multithreaded GC. Java experience shows that this is the future of GC.

[Wajinn]

Autofree is one of 4 ways to handle memory in V. The default one is a tracing GC, there's arena allocation with -prealloc, and manual memory management via -gc none.

Strongly believe that this kind of post and upcoming article is important to help neutralize some of the confusion and deceptive criticisms placed out there. Among the things that are done: 1) Critics who like pretending they don't know anything about V's memory management options. 2) Pretending not to understand what the words "option" or "optional" means, or that V's GC can be turned off. 3) Ridiculous smears of over any GC usage, as if it means to somehow be "inferior".

That V uses an optional GC by default is tremendously helpful and convenient to new and casual programmers. Not only that, (in addition to other safety features that V has), it provides a degree of memory safety which has repeatedly been recommended by various government organizations. Consequently, people can get started being productive with V much more rapidly, because they don't have to worry about manual memory management. They can more rapidly focus on getting results and solutions. When ready, the GC can be turned off, because they are actually dealing with a situation where doing so would be useful or are really that advanced of a programmer.

As V is a compiled programming language, whose optional GC can be turned off, means it can go about memory management in a number of ways that is highly competitive to any that exists. Thus arena allocators. Optional GC and arena allocator usage, can be more than enough to offset excessive fixation on autofree until it becomes more developed and advanced. These other options should definitely get more attention in the documentation.

V is definitely more than just being about autofree (which is a great feature and option), it's a good and useful programming language. Autofree is more like a "cherry on top". The addition of autofree, with the other memory management options, strengthens the already existing benefits of using V.

[MatejMagat305]

I m sorry if I tell somethig what sound like that I criticise V have GC, GC is amazing tool when person do not need optimalization ..., and I realy llove V s options and their combinations, really amazing job!

[ArtemkaKun]

Criticizing V is ok if there are proofs 😅

I just said that GCs in development all the time, since big languages like Java or C# relays only on GC, so GC can be good too (somewhere in the future). Ofc combination of autofree and GC will be superior in my opinion

[Ddiidev]

Criticizing V is ok if there are proofs 😅

I just said that GCs in development all the time, since big languages like Java or C# relays only on GC, so GC can be good too (somewhere in the future). Ofc combination of autofree and GC will be superior in my opinion

I use C# a lot.
And the truth is that for most things you don't need to change much because the .NET GC has evolved a lot (mainly .NET7), and it has been doing something that V was born doing, which is to reduce allocations by improving the generational heuristic , etc...

I liked the initial idea of autofree in V, but I realized that in the end the GC delivers very well!

[Wajinn]

Looking at this. I think this should also be put in V's official Blog (https://blog.vlang.io/), when ready. As it would have a better "aesthetic" and be more "linkable", in addition to be a place where new users can update themselves on things being emphasized for them to know.

[Anivie]

The article seems to lack an explanation of why autofree leads to worse performance compared to enabling GC?

[Wajinn]

The article seems to lack an explanation of why autofree leads to worse performance compared to enabling GC?

Actually, if we read carefully, it does give a "partial" explanation.

2. Allocated strings are cloned on assignments.

To ensure that string copies do not point to freed memory, they are always cloned. This is an expensive O(n) operation, and is the main reason autofree can be slower than V's default GC or manual management.

GC works unexpectedly well with V, because of its design. Though interestingly and recently, V has some upgraded string performance optimizations, so it looks like a recheck of its affects on this topic are necessary.

I integrated a GC just for a test, and was surprised at how well it worked with V, a very minimal language, that avoids doing unnecessary allocations in the first place by using value types, string buffers, promoting a simple abstraction-free code style.

We also have to keep in mind that V is a compiled language, so GC usage isn't as slow as some people might be thinking or don't know any better are saying, like as is the case in scripting or interpreted languages. Seems more experimentation is being done, to get greater performance, which is great for V users.

Autofree and arena allocators will likely always have a seat at the table, because GC is not best or usable in all cases. Thus the flexible memory management as described on the website. GC, in the case of V and its design, is a highly usable default to start with.

[Anivie]

After reading the documentation, it is clear that autofree can only resolve 90% of resource releases in most cases, so it doesn't seem to work on its own

[Wajinn]

After reading the documentation, it can be understood that autofree can only solve 90% of the release issues in most cases, therefore, it seems that it cannot work independently.

Presently, that's correct. But, it depends on the program and programmer, as to what that remaining percentage will be. It's also unclear if the remaining percentage might not be able to get to, if autofree were run without the GC as fallback, would be acceptable for the use case. Depending on how long the program intends to run, a "slow leak" could be acceptable and it would ordinarily never cause a problem. We should also keep in mind that the usage of the autofree option, can be easy enough. Particularly as it becomes more polished.

Additionally, some other form of GC or memory management could possibly be used to resolve the remaining percentage. It looks like a question of further study (which is happening), as to what's best. But clearly we already have a usable language and default that usually doesn't leak, is easy for many users, and is memory safe. The other options are about greater efficiency or best solution possible, which is a good problem to have.

[Avey777]

1. GC + Autofree (This is the default)
2. GC
3. Autofree
4. Manual

[i582]

Nope:

1. GC only (default)
2. Arena (-prealloc)
3. Autofree (-autofree)
4. Manual (-gc none)

[Avey777]

1. GC only (default) v run main.v
2. Arena (-prealloc) v -prealloc run mian.v
3. Autofree (-autofree) v -autofree run main.v
4. Manual (-gc none) v -gc none run .v

[ntrel]

If a variable results in an allocation, and this allocation is not used anywhere else, the variable is freed at the end of the block

Does not used anywhere else mean it isn't returned or its address taken? What about if it is assigned to something, is an implicit clone inserted for heap structs?

(2) seems to be missing the local string allocation's call to free:

fn foo() {
	s1 := 'hello'
	s2 := 'world'
	s := s1 + ' ' + s2
	str_copy := s.clone() // inserted by autofree
	do_stuff(str_copy)
	s.free() // inserted by autofree?
}

more to come soon

Was there any update on this? Presumably at least when a reference to heap memory is reassigned to something else, the original memory is also freed if unused?

[Avey777]

Autofree has been waiting too long, do I have to wait for another year or even longer

[Wajinn]

Autofree has been waiting too long, do I have to wait for another year or even longer

Seems a little pushy, when looking at this and the other thread (#20489), because the maintainer and other developers have responded to similar.

From the maintainer (last month and thread is linked above), "Autofree is not finished and not a priority until V 0.6, but it will be finished."

There is the GC to use, which covers most people. Really advanced users, can turn it off and manage manually. Maybe consider explaining what you are trying to do specifically and making the project public or at least put portions of code up on discord.

[Avey777]

Autofree has been waiting too long, do I have to wait for another year or even longer

Seems a little pushy, when looking at this and the other thread (#20489), because the maintainer and other developers have responded to similar.

From the maintainer (last month and thread is linked above), "Autofree is not finished and not a priority until V 0.6, but it will be finished."

There is the GC to use, which covers most people. Really advanced users, can turn it off and manage manually. Maybe consider explaining what you are trying to do specifically and making the project public or at least put portions of code up on discord.

Autofree is what I am looking forward to, I will continue to wait

[StunxFS]

Imho, I think that autofree should work with ARC, and not the way it currently "works", that way it would save a lot of having to use .clone() and memory management would be more lightweight.