The V Programming Language

Simple, fast, safe language created for developing Volt, soon available for everyone.

Open source release in June 2019. Early access since April 15.
Install V from source in 0.5 seconds
wget vlang.io/v.c && gcc -o v v.c
1.9k

Memory Management

Alex
Apr 15 · 3 min read
veryjos May 10 15:03
Has there been any discussion around memory management?

I'm curious what the plan is. GC is likely undesirable in a language like this, but some kind of refcounting in the stdlib makes sense.

Also, is it possible to allocate a struct on the stack (at least ergonomically, maybe by default)? The docs seem to suggest only heap allocations are possible.
medvednikov May 10 21:34
Structs are always allocated on the stack. Only structs declared with the & prefix are allocated on the heap. I'll make it more clear in the docs.

There will be no GC. Like the home page says, very simple cases are cleaned up. For the rest, manual memory management is required.

I have several ideas in mind, I'll work on implementing them in June.
ntrel May 11 07:28
> some kind of refcounting in the stdlib makes sense

Without destructors I don't think ref counting is possible to implement as a library.

> Only structs declared with the & prefix are allocated on the heap

If I understand correctly, escaping &struct_variable at some point in the function, even if not declared with &, will cause the struct to be heap allocated.

In fact, so long as the allocations aren't big, any non-escaping data can be stack allocated. So small arrays could be stack allocated if they aren't appended to.
medvednikov May 13 00:35
> In fact, so long as the allocations aren't big, any non-escaping data can be stack allocated. So small arrays could be stack allocated if they aren't appended to.

V is already using preallocated pools for small non-escaping strings. Can do the same for arrays.
dcurrie Jul 6 14:31
Looking at the V source code, there are some places where `free` is commented out, I'm guessing because it was causing problems. E.g. `pub fn (m map) free()` is a no-op. The "very basic automatic memory management" in `fn (p mut Parser) check_unused_variables()` is disabled.

I don't see a github issue for these things, though there is one for documenting this stuff: https://github.com/vlang/v/issues/274
There's also a feature request for destructors: https://github.com/vlang/v/issues/630

What's the plan for memory management? It's disconcerting to see memory management as a cleanup issue rather than a fundamental early design decision with support.
medvednikov Jul 13 22:48
@dcurrie

You are right, this is a very important problem that should have been resolved earlier.

I'll work on this starting tomorrow after the release of vweb and generics.

Here's the first discussion:

https://github.com/vlang/v/issues/1131
Log in via GitHub to comment



Powered by vtalk, open-source blogging/forum software written in V