--gc:none
This makes all new GC calls into malloc calls. But does not create free calls so your app will leak memory very fast.
--gc:boehm
Where can I find libbohem.dll for 64 bit windows? I was not able to compile it from source.
--gc:markAndSweep
How is this different from current GC?
--gc:regions --gc:stack
Gives a bility to define a memory region and then free at at once.
Is --gc:regions and --gc:stack same thing?
withScratchRegion:
# allocate stuff here and it will be freed when existing this region--gc:v2
Replaces incremental mark and sweep. It is not production ready yet, however.
Is this true?
-gc:go
Go people have put a ton of effort in getting their multi threaded GC to work. This uses their work in Nim.
Where can I find libgo.dll for 64 bit windows? I was not able to compile it from source.
--gc:destructors
A GC based on distructors. Appears not to work.
--gc:generational
Disabled and deprecated.
Should all code that points to it be removed?
I think Destructors and newruntime are on a pillow fight and only 1 will survive(?).
Boehm is actually often the fastest these days, and it has the best support for shared libraries and threading. Its downside is that it's not for realtime.
--newruntime is very likely to stay as the much better alternative for --gc:none.
Where can I find libbohem.dll for 64 bit windows? I was not able to compile it from source.
They are now included here
In https://github.com/nim-lang/Nim/blob/devel/compiler/commands.nim , at command line option "newruntime",
I could locate defineSymbol(conf.symbols, "nimV2") and conf.selectedGC = gcDestructors
So something like nimV2 and gcDestructors seems to exist. However, for this purpose, I expected (but failed) to find the new keywords owned, sink and lent in the lexer's token list. So, if not there, where are they?
Does Boehm work for threads and async?
For Destructors what function can I call to free?
Is it possible to use normal RefC for everything but use region's withScratchRegion for critical sections?
@Araq, may I remove v2, generational or stack from the code base? They appear to be disabled and deprecated and not documented.
However, for this purpose, I expected (but failed) to find the new keywords owned, sink and lent in the lexer's token list. So, if not there, where are they?
Oh simple, they are in system.nim, no need to make them keywords, Nim's syntax is flexible enough to allow for wordHere T.
@Sixte:
the new keywords owned, sink and lent...
As @Araq has explained as a follow-up, they are in the library system.nim, but they aren't explained very well or at all in the library documentation. The best source of documentation for them is the "destructors" document. The top part of this page describes Nim's implementation of destructor/assignment/move semantics including sink/=sink (move) and the bottom part the implementation of owned ref, lent, etc.
@treeform:
For Destructors what function can I call to free?
That's the point, with --gc:destructors you don't need to call anything to free standard library allocated items that allocate heap space as in string's and seq's as this turns on the generation of =destroy/=/=sink "hooks" for these whose functionality is as described in the above documentation. That said, the default destruction time is when the binding goes out of scope at the end of a proc and if one wants to force destruction, =destroy can be called whenever immediate destruction is desired.
For your own allocated pointers, you can tap into this at any time (you don't need the --gc:destuctors compiler flag) by wrapping them in an object for which you have defined your own custom override versions of these "hooks" that take care of destruction/assignment/move semantics; The compiler flag just makes it available automatically for the standard library structures.
Interest in this thread seems to have evaporated (as is often the case with some interesting forum threads, just as the one where @Araq promised to explain the direction memory management was going int the version 1.1 roadmap thread, in which interest has seemingly waned).
I got tired of waiting for the explanation of the "--gc:destructors" option and just read the source, with the following observations:
So to answer the question as follows:
For Destructors what function can I call to free?
the right answer is that you don't need to free manually because the custom memory management/garbage collector that you supply is expected to do it for you through use of the automatically called "hooks".
I'm sure that there are many in the dev team that know all of this and likely more, but it takes quite a long time for the information to be disseminated across to where it will readily pop up for a search such as in this forum; let alone the length of time it takes to be properly and completely documented in the official documentation. It I have made errors, please chip in with corrections, and if we can get the "full picture", let's look into doing a PR on the documentation to complete this...
I'm sure that there are many in the dev team that know all of this and likely more, but it takes quite a long time for the information to be disseminated across to where it will readily pop up for a search such as in this forum; let alone the length of time it takes to be properly and completely documented in the official documentation. It I have made errors, please chip in with corrections, and if we can get the "full picture", let's look into doing a PR on the documentation to complete this...
I'm sorry but I really want something that works before announcing it and documentation follows after a working implementation...
@Araq:
I'm sorry but I really want something that works before announcing it and documentation follows after a working implementation...
I'm sure everyone appreciates that, and it's obvious that we don't want to waste too much time on the documentation until things stabilize.
That said, there are experiments and failed experiments in the code base that are confusing for any programmers that are getting into Nim well after they were considered. For instance, of the actual ten methods of GC (eight plus "--gc:stack" - same as ""--gc:regions" and "--gc:none") as per the OP here, which doesn't include "--newruntime" which is another form of no GC, it would seem that at least two options (as in "--gc: generational" and "--gc:v2" have been dropped/depreciated and lead nowhere and there are no plans to advance them. It's true that one needs to read the source code to actually find the dropped ones, as they no longer even show up in "nim --fullhelp". However, of the others, there doesn't seem to be much explanation, even in the "garbage collection" document that seems to be very out-of-date.
When it comes to GC, Nim is getting to the state of too many options to try for someone new to Nim, without any documentation on the advantages and disadvantages of each. For instance, there isn't any documentation that says that both both the Boehm and Go (i think?) GC options support GC across threads of the older no-longer-advancing methods, what Regions GC does that makes it different, that MarkAndSweep is the more tunable GC as to real time latencies as compared to the default deferred RC (I think?). AFAICT, all of the above methods are stable and have been available for years and are unlikely to change, especially in light of evolving "better" ways such as the new "Destructors" methods of "araqsgc" or "newruntime".
There can also be the issue of somewhat confusing names/switches: "--gc:destructors" originally seems to have been conceived as a way of providing some sort of memory management based on the new destructors but with a GC "hook" option, but now the "destructors" part of that has been moved into a separate "--seqsv2" compiler switch, as the remaining purpose of the "--gc:destructors" switch seems to be to remove cruft (;-) ) as in by-passing "deepCopy" and various AST types of magic, as well as all forms of built in GC, leaving only whatever can be provided through the GC "hooks". A better name for it might be "--gc:nocrufthook" ;-) ; in fact it is evolving into something rather nice!
However, I wonder if it is getting ambiguous to do with the "--gc:none" switch: if the default for the "--gc:nocrufthook" were to "hook" the newObj hook to the appropriate allocator (regular or malloc) just as "--gc:none" does with the traverseObj hood hooked to a discard, then when no "hooks" are provided it would work as if "--gc:none" had been used but with the guarantee of no cruft; it would also not blow up when no implementation of the "hooks" were provided when ref's (including closures) were used, as "nogc" would then be the default. In order to be backward compatible, the "--gc:none" compiler switch could just activate this mode. I can think of no reason that one would want "nogc" with cruft, can you? I think doing it as proposed might actually decrease the code as in not turning off/bypassing/short-cutting the built-in GC in two places...
It's a minor quibble but while I highly applaud the cruft-removing "--seqsv2" switch, shouldn't it be more clear that this applies "destructors" to `string` as well as `seq` and be named "--seqstrv2"?