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

21–30 of 62 posts

Re: Real-Time Garbage Collection Is Real

#21

Post by lumpypua »

nraynaud wrote: post #9
lumpypua wrote: post #6

Earlier quoted context omitted.

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.

I do agree with this critique. Object allocation patterns that suck down space in a GC'ed system equally abuse a refcounting system, just you're paying in CPU time rather than memory.

Re: Real-Time Garbage Collection Is Real

#22

Post by ezy »

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 wrong. Swift gets this wrong, Go gets this wrong. Rust is probably a little better because it actually has a static idea of memory scope, but I haven't seen a way to swap out the memory allocator in various contexts.

Most projects I've been involved with have used region/arena allocators. Not only do you mostly avoid the non-determism of your average GC, but you avoid the hassle of fine grained reference counting (in most cases). This relies on you choosing the scopes for your regions appropriately, but there usually is a clear scope to attach things to (e.g. frames, iteration of an event loop, etc.).

Re: Real-Time Garbage Collection Is Real

#23

Post by bitwize »

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.

Re: Real-Time Garbage Collection Is Real

#24

Post by mnem »

tolmasky wrote: post #14
lumpypua wrote: post #6

Earlier quoted context omitted.

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.

There are certainly classes of mobile apps that need the guarantees of lower/deterministic memory usage. In my experience, that is not the common app being written however. These concerns seem largely like fantasies not backed up by any concrete evidence for your every-day twitter client/mail app/weather/whatever. Generic list-based apps simply do not need to be acting as if you need to squeeze every ounce out of the…

I would be quite surprised if most App Store games were created with Unity - it's expensive and (comparatively) cumbersome to develop in, especially if you're just using 2D graphics (even with the fancy new Unity2D stuff). I can't find any stats on mobile game engine use though, which is a shame because I think it would be interesting to know.

When creating Unity3D games, you have to be reasonably careful about garbage collection - lots of nasty performance dips result if you assume that it just works. Generally you have to cobble together a mixture of object pools and statements attempting to force collection at a convenient point in the game flow amongst other things. It would be quite nice if you could turn it off for specific portions of code :)

Re: Real-Time Garbage Collection Is Real

#25

Post by mamcx »

psykotic wrote: post #18
ltta wrote: post #12

Earlier quoted context omitted.

As far as I know ARC (like manual memory managenent) can lead to release cascades that can also cause application delays in games eg. Something you have to watch for. Malloc() and free() and equivalents do quite a bit of work under the hood (check today's linked tcmalloc article for example) that takes time.

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?"

Re: Real-Time Garbage Collection Is Real

#26

Post by mamcx »

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…

You are talking about a arena collector? Like this:

http://wiki.luajit.org/New-Garbage-Collector

Exist some pre-madethat can be used for a new project, for use with LLVM or luajit?

Re: Real-Time Garbage Collection Is Real

#27

Post by psykotic »

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?"

If the mass objects have trivial (ignorable) destructors and don't own any heap-allocated subobjects then it's not a problem. You can have top-level objects like levels or documents or sessions own everything directly and indirectly under them and allocate those things out of a private heap that can ideally be reused but otherwise be bulk freed in a few calls. Unfortunately, the standard C++ philosophy around RAII and value semantics works against this. Since there is something to be said for the elegance and upfront convenience of the value semantics approach, it comes down to a trade-off.

Re: Real-Time Garbage Collection Is Real

#28

Post by pjmlp »

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…

Why waiting?

http://www.atego.com/de/products/atego-perc/

https://www.aicas.com/cms/en/JamaicaVM

One good thing about Java is the vendor eco-system.

Re: Real-Time Garbage Collection Is Real

#29

Post by mnem »

mnem wrote: post #24
tolmasky wrote: post #14

Earlier quoted context omitted.

There are certainly classes of mobile apps that need the guarantees of lower/deterministic memory usage. In my experience, that is not the common app being written however. These concerns seem largely like fantasies not backed up by any concrete evidence for your every-day twitter client/mail app/weather/whatever. Generic list-based apps simply do not need to be acting as if you need to squeeze every ounce out of the…

I would be quite surprised if most App Store games were created with Unity - it's expensive and (comparatively) cumbersome to develop in, especially if you're just using 2D graphics (even with the fancy new Unity2D stuff). I can't find any stats on mobile game engine use though, which is a shame because I think it would be interesting to know. When creating Unity3D games, you have to be reasonably careful about garba…

Found some interesting statistics on this site: http://www.iresearchchina.com/views/5604.html

I suspect to get anything more detailed you may have to purchase a paid report from one of the various analytics companies.

Sorry, I've wandered rather off topic...

Re: Real-Time Garbage Collection Is Real

#30

Post by munificent »

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.

> are orders of magnitude slower

If this was true, an Android phone would refresh less than once per second. How about "why Android phones are maybe 20% slower" or some more actually within the bounds of reason number?

Post reply on HN