nimforum mirror - What would I lose if I turn of garbage collection?

DeletedUser (orginal) [2023-11-23T20:45:22+01:00] view original

What would I lose if I turn off the garbage collection and use manual memory management in Nim. I read somewhere that I would lose the goodness of the std library. Is that true? Is the manual memory management feature in Nim same as in C? I'm just asking out of curiosity.

ElegantBeef (orginal) [2023-11-23T20:51:20+01:00] view original

Anything in the stdlib that operates using automatic memory management seq, std/[sets, intsets, packedsets, tables, deques,....]. There is really no reason to disable automatic memory management in Nim since with Arc you can just write hooks and it'd be indistinguishable from the C without manual alloc and free calls. It's manual memory management you manage the lifetime of your heap allocated resources and have to insert your free calls where you want, no different to C, Zig, Odin, or any other manual managed language.

alireza (orginal) [2023-11-23T20:59:02+01:00] view original

also note that you cannot use arc with default asyncdispatch since it needs a cycle collector to free memory, there are other async implenetations that can be used with arc but not the default one as far as i know, you may also need that cycle collector for your own code as well if your code produces cycles, more on that here

https://nim-lang.org/docs/mm.html

and there

https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html

Araq (orginal) [2023-11-23T21:47:52+01:00] view original

Use ptr and use it "just like in C", no need to mess with the mm/gc switch.

termer (orginal) [2023-11-23T23:42:49+01:00] view original

Using --mm:none would be an unpleasant experience because you wouldn't be able to use managed reference types (such as anything that is or is based on a ref object) without leaking them. Just use --mm:arc if you don't want a GC at all. Objects with reference cycles will leak, but as long as you don't have any of those, everything will be handled for you, very similarly to how Rust does its memory management.

DeletedUser (orginal) [2023-11-24T05:26:43+01:00] view original

So, essentially, I go into manual memory management in Nim, it's a free fall and totally unsafe. That's nice to know (but also nice to know that one can code in Nim without any restrictions).

Araq (orginal) [2023-11-24T07:13:47+01:00] view original

As opposed to what? Sorry but you've no clue about these things.

If it's "manual" it cannot be "safe", by definition "manual" must allow for var x = alloc(10); dealloc(x); use x[] which is the classic "use after free" bug.

DeletedUser (orginal) [2023-11-24T09:05:59+01:00] view original

Oh, sorry, I did not express myself completely. I wasn't looking for "safe" nor was I assessing Nim's safety. I was doing the opposite. I am glad to know that the compiler doesn't restrict me in any way (w.r.t. memory management); if I read and understood everything mentioned by people here correctly. It should be free fall. Nim is my first systems programming language. I've learnt C and C++ but have never used or done anything much with them.

I'm just glad that I have unrestricted access to the inner components of a compiler through Nim with its awesome syntax.

DeletedUser (orginal) [2023-11-24T16:33:23+01:00] view original

"...internal components of a computer*..."

mratsim (orginal) [2023-12-05T11:16:13+01:00] view original

This is probably the largest Nim library written with manual memory management:

https://github.com/mratsim/constantine

See allocators: https://github.com/mratsim/constantine/blob/0a17002/constantine/platforms/allocs.nim#L72-L134

That said for core cryptography, it's all stack objects. I could use destructors hook for more "automated manual" memory management.

I do pass a lot of flags for ensuring correctness in my test suite: https://github.com/mratsim/constantine/blob/0a17002/constantine.nimble#L636-L661

const stackHardening =
    
    " --passC:-fstack-protector-strong " &
    
    # Fortify source wouldn't help us detect errors in Constantine
    # because everything is stack allocated
    # except with the threadpool:
    # - https://developers.redhat.com/blog/2021/04/16/broadening-compiler-checks-for-buffer-overflows-in-_fortify_source#what_s_next_for__fortify_source
    # - https://developers.redhat.com/articles/2023/02/06/how-improve-application-security-using-fortifysource3#how_to_improve_application_fortification
    # We also don't use memcpy as it is not constant-time and our copy is compile-time sized.
    
    " --passC:-D_FORTIFY_SOURCE=3 "
  
  const sanitizers =
    
    # Sanitizers are incompatible with nim default GC
    # The conservative stack scanning of Nim default GC triggers, alignment UB and stack-buffer-overflow check.
    # Address sanitizer requires free registers and needs to be disabled for some inline assembly files.
    # Ensure you use --mm:arc -d:useMalloc
    #
    # Sanitizers are deactivated by default as they slow down CI by at least 6x
    
    " --mm:arc -d:useMalloc" &
    " --passC:-fsanitize=undefined --passL:-fsanitize=undefined" &
    " --passC:-fsanitize=address --passL:-fsanitize=address" &
    " --passC:-fno-sanitize-recover" # Enforce crash on undefined behaviour

Mirror of forum.nim-lang.org

10676 :: What would I lose if I turn of garbage collection?