5 ms·

Something I'd like to see more of are GC and memory allocation guarantees, not just an option to disable it. Most of the time GC is fine as long as it's low en

by duped 5y ago

Something I'd like to see more of are GC and memory allocation guarantees, not just an option to disable it. Most of the time GC is fine as long as it's low enough latency. Where it matters you don't really want any memory management - which isn't useful, since the memory needs to me managed somewhere in the code. For that reason the pattern isn't to switch to a non-GC'd language because it doesn't have GC but because you can guarantee all the memory is allocated up front and that no freeing or allocation happens in the tight loops. That's not actually sufficient though. Even in production code bases accidental allocation can slip through. What you'd really like to see is a `no-alloc:` block which forbids operations that may allocate or free memory - GC'd or otherwise - and force the programmer to allocate before entering the block and free outside it.

mrec 5y ago
It's not production-ready and isn't a GC'd language, but Zig's approach might be to your taste: > Zig programmers must manage their own memory, and must handle memory allocation failure. > This is true of the Zig Standard Library as well. Any functions that need to allocate memory accept an allocator parameter. As a result, the Zig Standard Library can be used even for the freestanding target. https://ziglang.org/learn/overview/#manual-memory-management https://ziglang.org/learn/overview/#manual-memory-management
elcritch 5y ago
Nim's new garbage collector was designed with embedded systems in mind [1]. It uses non-atomic/non-locking reference counting combined with C++11 move semantics. The usage of move semantics enables both performance increases and a method to ensure memory is only "owned" by one thread (which enables non-atomic reference counting). Theres optional cycle collection support but I prefer to keep embedded code acyclical. On your second point you can use Nim's effect system to ensure no allocations occur in a given function or its callees. Currently no one has done this, and might be tricky with the reference counting, but not too difficult either. I used Nim with ARC for a latency sensitive embedded project. To avoid allocation on the tight reading loop I pre-allocated the values needed, or made them global variables. A few extra integer ops didn't matter, but allocation is sloooow. However, I'd eventually like to add allocation tracking to the effect system. Rather, make the existing effects more granular for this purpose. 1: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...
- irq-1 5y ago
  FYI there's also this newer document on memory management options: https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html
stephen82 5y ago
You are free to manage memory yourself, if that is what you mean [1]. [1] https://nelua.io/overview/#memory-management https://nelua.io/overview/#memory-management
- duped 5y ago
  That's not really what I meant. The example is showing the problem, the transition to manual memory management just makes it a bit easier to write a program without memory operations in critical sections. What I'm talking about is a hypothetical language that makes memory operations in critical sections forbidden and considered a compilation error.
  - com2kid 5y ago
    > What I'm talking about is a hypothetical language that makes memory operations in critical sections forbidden and considered a compilation error. This is easy to do in C, and you'll see it in embedded code. A simple preprocessor macro that redefined malloc to something that causes an error. To enable malloc in some chunk of code (embedded defaults to "malloc is bad"), you can define it accordingly in the .c files that need it.
  - p0nce 5y ago
    D has the @nogc attribute. Using it to make memory allocation forbidden in parts of the codebase.
  - stephen82 5y ago
    A discussion about GC and memory management can be found here https://github.com/edubart/nelua-lang/discussions/70 https://github.com/edubart/nelua-lang/discussions/70 Maybe it can answer to some parts of your reasoning? :/
  - auxym 5y ago
    This is possible in Nim using the "soft real-time" GC with "GC_step Mode" see https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html. You can even tell the GC how much time it can pause. But Nim also has a new deterministic GC, that has been available since 2020 and will be the default in a future version, see: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... In fact, I see many similarities between Nelua and Nim.
jasperry 5y ago
I've thought about something like this...that if a compiler could tell that code uses only stack-based allocation, it could turn off GC. Of course, that's very limiting, which is why we need more complicated things like Rust's type system to avoid GC.
- didibus 5y ago
  Java does that, both the HotSpot JIT and the AOT compiler (Substrate VM) I believe will do it. Now it can't always tell that data is local to the stack, but when it can, it won't allocate it on the Heap and will automatically switch to stack allocation (and no GC for it).

by duped 5y ago

mrec 5y ago

It's not production-ready and isn't a GC'd language, but Zig's approach might be to your taste: > Zig programmers must manage their own memory, and must handle memory allocation failure. > This is true of the Zig Standard Library as well. Any functions that need to allocate memory accept an allocator parameter. As a result, the Zig Standard Library can be used even for the freestanding target. https://ziglang.org/learn/overview/#manual-memory-management https://ziglang.org/learn/overview/#manual-memory-management

elcritch 5y ago

Nim's new garbage collector was designed with embedded systems in mind [1]. It uses non-atomic/non-locking reference counting combined with C++11 move semantics. The usage of move semantics enables both performance increases and a method to ensure memory is only "owned" by one thread (which enables non-atomic reference counting). Theres optional cycle collection support but I prefer to keep embedded code acyclical. On your second point you can use Nim's effect system to ensure no allocations occur in a given function or its callees. Currently no one has done this, and might be tricky with the reference counting, but not too difficult either. I used Nim with ARC for a latency sensitive embedded project. To avoid allocation on the tight reading loop I pre-allocated the values needed, or made them global variables. A few extra integer ops didn't matter, but allocation is sloooow. However, I'd eventually like to add allocation tracking to the effect system. Rather, make the existing effects more granular for this purpose. 1: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

irq-1 5y ago
FYI there's also this newer document on memory management options: https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html

stephen82 5y ago

You are free to manage memory yourself, if that is what you mean [1]. [1] https://nelua.io/overview/#memory-management https://nelua.io/overview/#memory-management

duped 5y ago
That's not really what I meant. The example is showing the problem, the transition to manual memory management just makes it a bit easier to write a program without memory operations in critical sections. What I'm talking about is a hypothetical language that makes memory operations in critical sections forbidden and considered a compilation error.
- com2kid 5y ago
  > What I'm talking about is a hypothetical language that makes memory operations in critical sections forbidden and considered a compilation error. This is easy to do in C, and you'll see it in embedded code. A simple preprocessor macro that redefined malloc to something that causes an error. To enable malloc in some chunk of code (embedded defaults to "malloc is bad"), you can define it accordingly in the .c files that need it.
- p0nce 5y ago
  D has the @nogc attribute. Using it to make memory allocation forbidden in parts of the codebase.
- stephen82 5y ago
  A discussion about GC and memory management can be found here https://github.com/edubart/nelua-lang/discussions/70 https://github.com/edubart/nelua-lang/discussions/70 Maybe it can answer to some parts of your reasoning? :/
- auxym 5y ago
  This is possible in Nim using the "soft real-time" GC with "GC_step Mode" see https://nim-lang.org/docs/gc.html https://nim-lang.org/docs/gc.html. You can even tell the GC how much time it can pause. But Nim also has a new deterministic GC, that has been available since 2020 and will be the default in a future version, see: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... In fact, I see many similarities between Nelua and Nim.

jasperry 5y ago

I've thought about something like this...that if a compiler could tell that code uses only stack-based allocation, it could turn off GC. Of course, that's very limiting, which is why we need more complicated things like Rust's type system to avoid GC.

didibus 5y ago
Java does that, both the HotSpot JIT and the AOT compiler (Substrate VM) I believe will do it. Now it can't always tell that data is local to the stack, but when it can, it won't allocate it on the Heap and will automatically switch to stack allocation (and no GC for it).