Real-Time Garbage Collection Is Real
michaelrbernste.in
Real-Time Garbage Collection Is Real
1–10 of 62 posts
Re: Real-Time Garbage Collection Is Real
#2I think more languages should adopt Swift and Objective-C's automatic reference counting. The only downside to ARC is retain cycle's which rarely happen in my experiance. A deterministic object life cycle just feels right.
Re: Real-Time Garbage Collection Is Real
#3man 3 free
Re: Real-Time Garbage Collection Is Real
#4I think more languages should adopt Swift and Objective-C's automatic reference counting. The only downside to ARC is retain cycle's which rarely happen in my experiance. A deterministic object life cycle just feels right.
"The only downside to ARC is retain cycles"
Does ARC allow moving? If not, what happens when your heap becomes fragmented? Isn't that a downside?
Another downside is that many lock-free data-structures require a GC.
Re: Real-Time Garbage Collection Is Real
#5I think more languages should adopt Swift and Objective-C's automatic reference counting. The only downside to ARC is retain cycle's which rarely happen in my experiance. A deterministic object life cycle just feels right.
> The only downside to ARC
Doesn't reference counting typically have a worse throughput than garbage collection? That's what I've read anyway.
Re: Real-Time Garbage Collection Is Real
#6I think more languages should adopt Swift and Objective-C's automatic reference counting. The only downside to ARC is retain cycle's which rarely happen in my experiance. A deterministic object life cycle just feels right.
> The only downside to ARC Doesn't reference counting typically have a worse throughput than garbage collection? That's what I've read anyway.
GC has better throughput at the expense of significantly increased memory usage, and variable latency for any individual task.
On servers, that's fine.
On my phone, I'll take lower memory usage and predictable latency any day.
Yay refcounting.
Re: Real-Time Garbage Collection Is Real
#7man 3 free
A typical implementation of free(3) does not give real-time guarantees; whether you use GC or not, you need to know things about your allocator to have any kind of latency guarantees. I get a little disturbed when people treat malloc() and free() as if they were constant-time operations.
Re: Real-Time Garbage Collection Is Real
#8I think more languages should adopt Swift and Objective-C's automatic reference counting. The only downside to ARC is retain cycle's which rarely happen in my experiance. A deterministic object life cycle just feels right.
I had big troubles with cycles, the trick is that you don't know that you are leaking until it's too late.
Another trouble is the cache pollution.
Re: Real-Time Garbage Collection Is Real
#9Earlier quoted context omitted.
> The only downside to ARC Doesn't reference counting typically have a worse throughput than garbage collection? That's what I've read anyway.
GC has better throughput at the expense of significantly increased memory usage, and variable latency for any individual task. On servers, that's fine. On my phone, I'll take lower memory usage and predictable latency any day. Yay refcounting.
it's not really "significant" if you don't optimise it that way. It's only the first generation scavenger that needs space for breathing.
Re: Real-Time Garbage Collection Is Real
#10man 3 free
A typical implementation of free(3) does not give real-time guarantees; whether you use GC or not, you need to know things about your allocator to have any kind of latency guarantees. I get a little disturbed when people treat malloc() and free() as if they were constant-time operations.
more exactly malloc and free typically gives you shitty time guarantee.
The usual thing people do in real time is bailing out of any dynamic allocation, they know malloc is not good, they are afraid or don't want to deal with real time GC, and/or they know that if they do all the allocation first, they have a grasp on the worst case of their loop (I think the real answer is that it's a tradition).