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.
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.
> 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.
> 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.
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.
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:
An option could be to explore the (scant) comp-sci literature on compile-time garbage collection (CTGC).
It's usually directed towards declarative programming languages but a recent (2017) PhD thesis is about CTGC in the context of system programming languages with imperative features (like mutability).
V is an imperative language with features (immutability, pure functions, …) that encourages functional programming style, so it could be (I haven't read this thesis yet) a good target for CTGC.
Reference: "ASAP: As Static As Possible memory management", by Raphaël L. Proust
Jan 5 18:13
I sent an email to Raphaël, he is interested in implementing "As Static As Possible memory management" for V language.
- ASAP should be implementable in V
- The hardest thing is going to be working with mutable collections that are integer-indexed
He is involved in other short-term projects, but can provide support for this task if someon
e else start working on.
His email is:
Jan 10 16:11
Between very simple cases and memory management with pointers,
how about have memory pool (and its methods) included in the language?
When creating a pool, the programmer must define its size.
Jan 10 16:30
I really like this story "An Early History of Pony" or why Sylvan Clebsch has created Pony
Feb 8 13:37
I have been waiting impatiently for V to deliver on its promises of no undefined behaviour, which instinctively (to me) leads to lock free, race free, leak free and auto destruct. If I thought GC was ok, then I'd be keen on Pony or Haskell. Recently Discord published an article why they left Go for Rust (https://blog.discordapp.com/why-discord-is-switching-from-go-to
-rust-a190bbca2b1f), and I'm thinking, that could/should have been V.
I had no idea (and still don't), how hard this stuff is to pull off. For example, I never thought about immutable data needing to be released (until a read a comment somewhere here about immutable trees). I don't like the overheads of GC, but I don't like rust's lifetimes either, and
I really like V's Go like syntax.
I thought of a naive memory model where each value/memory location could only be referenced by a single variable. Probably easier to implement than most lock, race and leak free solutions, but would also be slow or use hideous amounts of RAM in certain situations.
I know there's some cool libraries being worked on, but I feel th
Feb 8 13:38
I know there's some cool libraries being worked on, but I feel this needs to be priority. If this is solved (elegantly), it could attract devs like myself and we would write cool libraries for V. Lots of them.
I'm adding ASAP to my reading list, but please, this needs some love.
Feb 9 08:57
I am not quite sure what solution will be in the end but this paper seems to be influential for V
Memory Management in Lobster:
Log in via GitHub to comment
, open-source blogging/forum software written in V