9 ms·
There are a lot of gotchas with the new GC that make me nervous about this release: > As far as we know, ARC works with the complete standard library except fo
by Boxxed 6y ago
There are a lot of gotchas with the new GC that make me nervous about this release:
> As far as we know, ARC works with the complete standard library except for the current implementation of async...
That's not a great endorsement...
> If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc.
Seems like this is a big onus to put on the user -- it's tough to prove a negative like this.
- nicoburns 6y agoLooks like it'a still an opt-in experimental option at this point rather than the default. Preaumably they'll fix these caveats before recommending it for general use.
- Tiberium 6y agoSorry if you got misled by the article - ORC is what you should use if your program has cycles. ORC deals with async just fine.
- MaxBarraclough 6y agoDoes ORC stand for something?
- cb321 6y agoI could be wrong, but I believe the acronyms are: ARC = Automatic Reference Counting (NOTE: not Atomic) ORC = Optimized Reference Counting The loopy/circular character of the letter 'O' may be a secondary mnemonic since it collects cycles.
- cb321 6y agoI meant "character" as in "nature" not as in the prog.lang "character type"..I just realized that in context this might be confusing. Lol.
- djur 6y agoI think you missed this detail: > ARC was first shipped with Nim 1.2... [ORC is] our main new feature for this release Seems like they should phrase it like "use ORC unless you know you don't have cycles" rather than "use ORC if you're not sure you have cycles", but that's a reasonable responsibility to take on if you're choosing to use an alternative garbage collector.
- mumblemumble 6y agoI'd prefer no phrasing at all. Just pick one that will work well in all cases, and don't give me any footguns.
- adamc 6y agoYes. Or at least put them in the appendix.
- judofyr 6y agoTo clarify: By default Nim will still use the GC which doesn't have any "footguns". ARC and ORC are new features which have different trade-offs, and some limitations. You opt-in to using them if you're interested.
- deleted 6y ago[deleted]
- gameswithgo 6y agoA way of dealing with memory that works well in all cases! That would be great.
- leorize 6y agoI believe the phrasing might not be clear to everyone, so here's a reduced version: * Nim's current async implementation creates a lot of cycles in the graph, so ARC can't collect them. * ORC is then developed as ARC + cycle collector to solve this issue, and it has been a success. * This 1.4 release introduces ORC to everyone so that we can have mass testing for this new GC and eventually move torwards ORC as the default GC. TL;DR: ORC works with everything† and will be the new default GC in the future. Your old Nim code will continue to work, and will just get faster‡. † We are not sure that it's bug-free yet, which is why it's not the default for this release. ‡ Most of the time ORC speeds things up, but there are edge cases where it might slow things down. You're encouraged to test your code with --gc:orc against our default GC and report performance regressions.
- treeform 6y agoYour explanation is very clear. Thanks.
- wffurr 6y agoIs there an msan/asan equivalent that can detect leaks in your test suite?
- leorize 6y agoYes, we use valgrind for the compiler and stdlib test suite. The testament tool supports this, however it's not in widespread use outside of the compiler and stdlib, so documentation is rather sparse. Since Nim uses the C compiler to generate executables, you should be able to use `--passC:-fsanitize=memory --passL:-fsanitize=memory` to enable msan. For maximum effectiveness the flags `-d:useMalloc --gc:orc` should also be used. `-d:useMalloc` tells Nim to allocate memory using libc's malloc instead of our TSLF implementation. This should provide adequate compatibility for use with external inspection tools. We do `--gc:orc` because this is one of the only GCs that support -d:useMalloc (the other being arc).
- scns 6y agoPlease put this in the docs, if it is not there already
- karmakaze 6y agoI'm not familiar with Nim. Does it also support weak references? A significant portion of the problems with cycles in ARC are parent references.
- planetis 6y agoWeak references are possible with the .cursor pragma applied on local variables and object fields. This release introduces cursor inference too, enabled by default with --gc:arc|orc, but only for local variables.
- mcintyre1994 6y agoAt an ELI5 level, does anyone know why Swift can have ARC and async but Nim's ARC doesn't work with async? Is it just implementation details of Nim's async specifically instead of anything more fundamental to ARC? Just asking out of curiosity.
- treeform 6y agoYes. There is nothing fundamental to nim's ARC working with nim's async. There are attempts on make nim's async cycle free.
- dom96 6y agoNote that what we're referring to as "async" for Nim is actually "async await". AFAIK Swift doesn't support that, does it?
- darthrupert 6y agoSwift doesn't claim hard realtime capabilities like Nim's ARC does.