nimforum mirror - Update on --gc:arc

Araq (orginal) [2020-07-16T12:06:11+02:00] view original

Couldn't render post #40506.

treeform (orginal) [2020-07-16T23:10:07+02:00] view original

This arc stuff has been great! Some questions:

Will --gc:arc or --gc:orc become the default?

When will it become the default?

Is there a way to use --gc:orc in development so that it alerts us about cycles (echo when and where it frees them) but then switch to --gc:arc when you are confident in no cycles in your code?

If you share a ref based tree data structure between threads, can you safely read from it without locking? Or locks are required for both reading and writing?

Is it still safe to cast from string to seq[uint8] and back? How is 0 terminator handled?

Does let a = b increased b's reference count?

Under what conditions the cycle scanner for --gc:orc runs? After 1 free, after N frees, after X ms?

Yardanico (orginal) [2020-07-16T23:23:46+02:00] view original

As far as I know - ORC, to be a more complete replacement. But library authors are advised to test with ARC (if they don't have cyclic structures of course)

At least not until the compiler could work with ARC/ORC without any issues. But then we need to make sure that popular libraries work with ARC/ORC without any issues.

It's still the same as far as I know - strings and seqs still have the same internal memory layout, you can check at https://github.com/nim-lang/Nim/blob/devel/lib/system/seqs_v2.nim#L17 and https://github.com/nim-lang/Nim/blob/devel/lib/system/strs_v2.nim#L12 . Not sure how the 0 terminator is handled, but it's not there in the resulting sequence.

With latest optimizations if the compiler decides that this can be a cursor, it won't do that at all. But otherwise - sure (if there's actual refcounting involved - if it's a ref type)

P.S.: I'm not 100% sure that my answers are correct :D

Araq (orginal) [2020-07-17T10:01:25+02:00] view original

1-2) I plan to make --gc:orc the default once bootstrapping works.

Good idea and simple to implement.

Well you cannot share them, you can move them around. :-)

Still safe and there is no logic for the terminating zero, beware. (The old runtime also has no logic for it!)

Depends. That's what we got --expandArc for.

After N "cycle candidates in the queue". You can control it via GC_enableMarkAndSweep (poorly named now! This name didn't age well...)

juancarlospaco (orginal) [2020-07-17T14:56:43+02:00] view original

It says it works per-scope, so using block: or block someName: has overhead like for a loop?.

Araq (orginal) [2020-07-17T18:17:54+02:00] view original

The final (I hope) ARC/ORC related RFC has arrived: https://github.com/nim-lang/RFCs/issues/244

Finally addressing multi-threading aspects.

snej (orginal) [2020-07-17T18:26:40+02:00] view original

If you share a ref based tree data structure between threads, can you safely read from it without locking?

My understanding is that, since ARC does not use atomic inc/dec, even reading without locks would be dangerous since the refcounts could become corrupted. Even read-only access can generated retain/release pairs.

Araq (orginal) [2020-07-17T18:59:11+02:00] view original

Well, you don't share at all, you move data around. If you need real sharing, you should use the upcoming fusion support libraries, see https://github.com/nim-lang/fusion/pull/8

Araq (orginal) [2020-09-16T23:35:47+02:00] view original

Update: deepCopy and marshal.nim are now supported with ORC/ARC.

slonik_az (orginal) [2020-09-17T00:22:45+02:00] view original

@Araq: Congratulations on a great milestone!

Any guidance on when the next release with ORC/ARC as default GC will see the light of the day?

--Leo

Sixte (orginal) [2020-09-22T21:26:02+02:00] view original

The old refcounted gc relied on a scan of the stack. arc/orc works strictly pointwise instead, no stack scan anymore.

elcritch (orginal) [2020-09-25T06:34:51+02:00] view original

Async and ORC works on embedded!

Unfortunately, the GC trigger point / cycle count limit is set too high for embedded usage. On my desktop a simple asynchttpserver serves about 400 requests before running the cycle collector. Embedded crashes after about 10 requests. I tried GC_enableMarkAndSweep but it didn't appear to change when cycle collection occurs. However, GC_fullCollect does force a full cycle collect.

For general usage, I'd prefer being able to modify when ORC runs collections. For embedded it needs to be as small as possible! A few extra cycles running the GC are often preferred given the lack of memory. I've tried setting InitialCycleThreshold and InitialZctThreshold but without much effect. Is there an appropriate parameter for minimizing the absolute memory usage?

Araq (orginal) [2020-09-25T07:46:01+02:00] view original

The setting to tweak is in lib/system/orc.nim, const defaultThreshold. PRs are welcome.

elcritch (orginal) [2020-09-25T17:52:46+02:00] view original

Fantastic! Found a flag nimAdaptiveOrc that works. In the future it may make sense to make defaultThreshold fully user adjustable, but it seems 128 is a decent default for ESP32 chip. I'll make a PR for another flag if it becomes an issue. Also, the GC_fullCollect is useful. I'll add them both to the embedded docs in a PR when I get time to (may be a while).

cdunn2001 (orginal) [2020-09-28T20:07:21+02:00] view original

I'm confused. On the one hand, "Offers a shared heap." But on the other hand, "Well you cannot share them, you can move them around."

If there is a shared heap, why can't we share?

Araq (orginal) [2020-09-28T20:39:55+02:00] view original

Please read https://github.com/nim-lang/RFCs/issues/244 for more information.

e (orginal) [2020-09-29T15:18:47+02:00] view original

Will immutable imply isolated? The RFC244 doesn't say so, but write-tracking is coming, and would make sharing immutable structures possible.

Araq (orginal) [2020-09-29T16:06:54+02:00] view original

No, immutable data structures continue to be problematic for non-atomic reference counts. But you can use atomic reference counting for that and hack around the fact that it is "logically immutable -- except for the reference count operations".

snej (orginal) [2020-09-30T20:01:49+02:00] view original

If there is a shared heap, why can't we share?

Because ref-count inc/dec operations are not atomic. (Atomic ops are an order of magnitude slower.) That means if the same object has references on multiple threads, its ref-count can get corrupted by overlapping reads/writes.

The advantage of the shared heap (over the old per-thread heaps) is that an object reference can trivially be moved from one thread to another, just by passing a pointer. This is exactly the same thing Rust does.

Mirror of forum.nim-lang.org

6549 :: Update on --gc:arc