Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Real-Time Garbage Collection Is Real

michaelrbernste.in

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Real-Time Garbage Collection Is Real

#41

Post by pshc »

AceJohnny2 wrote: post #37
pshc wrote: post #36

I feel like GC is an evolutionary dead end. Too much indeterminism and action-at-a-distance. Rust and virtual reality are two clear indicators to me that we're exiting the age of GC; the opposition isn't just Apple anymore, though they dealt the first blow.

what's virtual reality in this context?

Oculus Rift and friends. VR needs extremely consistent latency and has very tight deadlines. Ideally, you render 90 FPS and never miss a frame.

GC pauses are out of the question, so if you're going to use GC, you need to be real-time without any degenerate stop-the-world cases. The linked article ostensibly delivers this, but there's no real-world evidence. Given your tight time budget, you also don't want to pay the "GC tax". GC just makes your life harder in this environment.

There also isn't really any good reason to write a 3D engine in GC'd languages given a) existing C++ engines and b) sightings of Rust on the horizon.

Re: Real-Time Garbage Collection Is Real

#42

Post by AceJohnny2 »

pshc wrote: post #41
AceJohnny2 wrote: post #37

Earlier quoted context omitted.

what's virtual reality in this context?

Oculus Rift and friends. VR needs extremely consistent latency and has very tight deadlines. Ideally, you render 90 FPS and never miss a frame. GC pauses are out of the question, so if you're going to use GC, you need to be real-time without any degenerate stop-the-world cases. The linked article ostensibly delivers this, but there's no real-world evidence. Given your tight time budget, you also don't want to pay the…

Ah, when lumped with GC I was wondering if there was a new trend in memory management that was confusingly called VR as well :)

Re: Real-Time Garbage Collection Is Real

#43

Post by kevinnk »

ezy wrote: post #22
youngthugger wrote: post #2

I 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 prefer well known memory lifetimes, but I'm undecided about ARC (or somewhat equivalently: std::shared_ptr, etc.). It can be a little confusing and overwrought at times, and I don't think the lifetimes are as clear as they could be. IMO, more languages shouldn't assume that there is a single memory allocator. That's one of the worst assumptions I see in systems languages -- even C++ (before C++11) got this entirely…

Maybe you're referring to something else, but std::allocator was in c++98

Re: Real-Time Garbage Collection Is Real

#44

Post by ezy »

kevinnk wrote: post #43
ezy wrote: post #22

Earlier quoted context omitted.

I prefer well known memory lifetimes, but I'm undecided about ARC (or somewhat equivalently: std::shared_ptr, etc.). It can be a little confusing and overwrought at times, and I don't think the lifetimes are as clear as they could be. IMO, more languages shouldn't assume that there is a single memory allocator. That's one of the worst assumptions I see in systems languages -- even C++ (before C++11) got this entirely…

Maybe you're referring to something else, but std::allocator was in c++98

Yes, but (according to the spec) it was stateless -- which made it worthless for the purposes I'm describing. The original purpose was to support custom static strategies for allocation (e.g. i86 near/far pointers or one memory pool for one kind of object for the whole program), not dynamic memory pools and arenas. C++11 fixed that, which is why I mentioned it.

That said, by C++03, most STL implementations supported stateful allocators (and that's what I've used when I've had to use C++), but the standard took a while to catch up.

Re: Real-Time Garbage Collection Is Real

#45

Post by Ded7xSEoPKYNsDd »

mamcx wrote: post #25
psykotic wrote: post #18

Earlier quoted context omitted.

Release cascades can be a big problem even with plain old RAII in C++. I once diagnosed a performance issue in a C++ network server where the server listening thread would sometimes temporarily hang when clients disconnected. The culprit turned out to be the destructor of a large std::map that directly and indirectly accounted for tens of millions of heap-allocated objects that had to be individually destructed and f…

So, what do? Perhapsh mark a object as "kill me without mercy?"

This is just an idea, but how about adding a function to your allocator that turns all future deallocations into a no-op?

Re: Real-Time Garbage Collection Is Real

#46

Post by Dewie »

How does regions fit into this? IIRC regions have deterministic lifetimes, and all values/objects allocated in a region are freed in bulk when the region is freed (so it seems to only depend on how complex the underlying allocation is).

http://en.wikipedia.org/wiki/Region-based_memory_management

Re: Real-Time Garbage Collection Is Real

#47

Post by bad_user »

lumpypua wrote: post #6
Dewie wrote: post #5

Earlier 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.

Ref counting is not deterministic. First of all because while looping on an atomic reference is non blocking, it is not wait free. Malloc/free are not deterministic either, can be quite expensive and while real-time implementations exist, that's not the malloc/free you end up using. With a generational GC allocating new objects involves just incrementing a pointer, deallocating short lived objects happens in bulk, so the cost for short-lived objects is similar to stack allocation. With ref counting memory gets fragmented, apps like Firefox have been suffering for years from fragmentation and for Firefox there was a sustained and very significant effort to fix it.

This can only be solved by either doing stack allocation or by building object pools. And this is for people that know what they are doing.

Rust is the only language (I know) that tries solving this with the ownership concept in the language, but then Rust will have problems in implementing immutable data structures that can be shared amongst threads, data structures which are doing structural sharing, so people will expect reads to scale, except there will be non-obvious contention happening due to usage of reference counting.

The latency in state of the art mainstream GCs is also NOT variable. Good garbage collectors allow you to control the max latency and frequency of STW pauses. That is not the issue for real-time requirements - the issue with real-time being that STW is unacceptable. But so is reference counting.

On the memory requirements, I don't buy it. My Android phone has more memory and more CPU capacity than my computer did 7 years ago. And I'm not seeing a difference in behavior to my iPad. Surely for games it pretty bad to drop frames, but most apps are not games and games are using highly optimized engines built in C++anyway.

Re: Real-Time Garbage Collection Is Real

#48

Post by bad_user »

ajross wrote: post #20

> It turns out that RTGC is very real, and research on it is very active. I remember being promised the same stuff at JavaOne in 1997. It's a solved problem, we're just waiting on an implementation. We're still waiting. That doesn't mean any of this stuff isn't interesting (though I gotta be honest it's getting less so for me every year), or that such a thing is impossible. But that title is dancing around a rather d…

At least a commercial JVM with a nonblocking GC is available and people are using it for real time stuff in the finance industry - http://www.azulsystems.com/

Re: Real-Time Garbage Collection Is Real

#49

Post by thoughtpolice »

pshc wrote: post #36

I feel like GC is an evolutionary dead end. Too much indeterminism and action-at-a-distance. Rust and virtual reality are two clear indicators to me that we're exiting the age of GC; the opposition isn't just Apple anymore, though they dealt the first blow.

TIL Rust will be single-handedly used to rewrite every single GC'd program in existence, and furthermore only VR systems like Oculus will be relevant after that, so why bother dealing with any of the actually-hard problems of the real world and improving the existing technology we'll have today, and for years to come?

Good to know.

Re: Real-Time Garbage Collection Is Real

#50

Post by bad_user »

bitwize wrote: post #23

One of the reasons why Lisp is fading into irrelevance is that GC is obsolete tech. You should be using RAII, smart pointers, or ARC for all dynamic-lifetime resource management depending on language and toolset for completely deterministic object lifetimes. This is also a factor in why Android phones are orders of magnitude slower than equivalently-specced iPhones, even with the new ART.

It's funny that whenever Apple does something, it shifts fashion. Reference counting is suddenly hip, when garbage collectors have been invented to solve problems with reference counting and those problems are still there with ARC.

I'm waiting for the day in which Apple will introduce an optinal GC as alternative to ARC on iOS, along with proclaiming red as the new purple.

Post reply on HN