5 ms·

> Golang said you should avoid using numbers greater than about 20k in your program to avoid GC problems Isn't this unavoidable with conservative garbage colle

> Golang said you should avoid using numbers greater than about 20k in your program to avoid GC problems Isn't this unavoidable with conservative garbage collectors? The GC looks at your fields and believes your integer is a pointer… It cannot know better. Swift doesn't have that issue, but reference counting has its own risks of memory leaks through mishandled weak references, and a performance overhead.

Dylan16807 10y ago
If you really want to use a conservative GC, you should not use the top or bottom of your address space for heap.
solidsnack9000 10y ago
Scanning the heap looking for values that "look like pointers" in some indefinite way is a fairly unusual strategy. There are many GC'd languages -- Haskell and O'Caml come to mind -- without this limitation. Haskell used "pointer tagging" where every value had two bits reserved at the top end and thus Ints were limited to 30 bits. The two bits were used to tell the GC what it was looking at. Later developments side-stepped this limitation but I'm not sure how. Does ARC have an overhead relative to GC? If if it does, it at least prevents latency spikes.
- Someone 10y ago
  "Does ARC have an overhead relative to GC? If if it does, it at least prevents latency spikes" It doesn't prevent latency spikes. As an extreme example, create a linked list or tree with a billion nodes, and let its root go out of scope. That will call free a billion times.
  - deleted 10y ago
    [deleted]
  - solidsnack9000 10y ago
    Do that every request, and it will be the same each time. With GC, you can see a latency spike when every request creates such a list and they aren't freed until, due to memory pressure, many are freed all at once. Some of the requests will get stuck waiting for a linked list node and have very high latency relative to the other ones. The strength of ARC for interactive applications is its consistency.

Dylan16807 10y ago

If you really want to use a conservative GC, you should not use the top or bottom of your address space for heap.

solidsnack9000 10y ago

Scanning the heap looking for values that "look like pointers" in some indefinite way is a fairly unusual strategy. There are many GC'd languages -- Haskell and O'Caml come to mind -- without this limitation. Haskell used "pointer tagging" where every value had two bits reserved at the top end and thus Ints were limited to 30 bits. The two bits were used to tell the GC what it was looking at. Later developments side-stepped this limitation but I'm not sure how. Does ARC have an overhead relative to GC? If if it does, it at least prevents latency spikes.

Someone 10y ago
"Does ARC have an overhead relative to GC? If if it does, it at least prevents latency spikes" It doesn't prevent latency spikes. As an extreme example, create a linked list or tree with a billion nodes, and let its root go out of scope. That will call free a billion times.
- deleted 10y ago
  [deleted]
- solidsnack9000 10y ago
  Do that every request, and it will be the same each time. With GC, you can see a latency spike when every request creates such a list and they aren't freed until, due to memory pressure, many are freed all at once. Some of the requests will get stuck waiting for a linked list node and have very high latency relative to the other ones. The strength of ARC for interactive applications is its consistency.