3 ms·
> you only trace when you hit cycles How do you tell when you've hit a cycle? > hopefully design your language semantics to discourage cycles Why? Cyclical
by lisper 11mo ago
> you only trace when you hit cycles
How do you tell when you've hit a cycle?
> hopefully design your language semantics to discourage cycles
Why? Cyclical structures can be very useful. For example, it can be very handy in many situations for a contained object to have a back-pointer to its container.
[UPDATE] Two responses have now pointed out that this particular case can be handled with weak pointers. But then I can just point to a general graph as an example where that won't work.
- vlovich123 11mo ago> For example, it can be very handy in many situations for a contained object to have a back-pointer to its container. Does it frequently need an owning reference though or would a weak reference suffice? Usually the latter situation suffices.
- lisper 11mo agoA fair point, but then you're still putting the burden on the programmer to figure out where a weak reference is appropriate. But then I'll just choose a different example, like a general graph.
- zozbot234 11mo ago> For example, it can be very handy in many situations for a contained object to have a back-pointer to its container. That's not a true cycle, it's just a back link for which "weak" reference counts suffice. The containment relation implies that the container "owns" the object, so we don't need to worry about the case where the container might just go away without dropping its contents first. (Edit: I agree that when dealing with a truly general graph some form of tracing is the best approach. These problem domains are where tracing GC really helps.)
- lisper 11mo agoOK, then I'll pick a different example: a general graph.
- mwkaufma 11mo ago"How do you apply algo X to a problem which has been narrowly-tailored and/or under-specified to specifically exclude X" isn't exactly a constructive inquiry.
- lisper 11mo agoA general graph is not exactly "narrowly tailored". Graphs are pretty common.
- mwkaufma 11mo agoNo but they are under-specified. OP is specifically working with a document-hierarchy data-structure with a natural ownership/weak-pointer distinction to exploit -- no need to abstract it to a general graph.
- lisper 11mo agoYes, but then they also said: > hopefully design your language semantics to discourage cycles thus expanding the scope of their comment beyond that specific use case.
- mwkaufma 11mo agoYes, but they said that in the context of a tailored language for persistent/HDD-backed data, where implicitly performance crosses the line into an additional measure of correctness, rather than an orthogonal one. ("to find live references means walking nearly the entire heap including the portions living in secondary storage, and now you're in a world of pain") So the "increased cognitive overhead" is intrinsic to the problem domain, not an unforced defect of the language design. Overgeneralization in such a case would induce even worse overhead as there'd be no user-level way to fix perf.
- lisper 11mo ago
- cmrdporcupine 11mo ago> How do you tell when you've hit a cycle? https://pages.cs.wisc.edu/~cymen/misc/interests/Bacon01Concurrent.pdf https://pages.cs.wisc.edu/~cymen/misc/interests/Bacon01Concu... TLDR there are heuristics which can give you a hint. And then you trigger a local trace to see. > Why? Because then you incur the cost of a trace -- and potentially paging in from slow-slow disk -- vs a simple atomic refcount. Even just a localized trace on live objects is a pointer-chasing cache & branch prediction killer.