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

31–40 of 62 posts

Re: Real-Time Garbage Collection Is Real

#31

Post by m0th87 »

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.

> One of the reasons why Lisp is fading into irrelevance is that GC is obsolete tech.

RAII, smart pointers and ARC aren't free lunches, which is why people had moved from them to GC in the first place.

Of the top 10 languages on github [1] that require memory management, 7 of them use GC [2].

> This is also a factor in why Android phones are orders of magnitude slower than equivalently-specced iPhones

That's a pretty nutty assertion to make without data.

1: http://adambard.com/blog/top-github-languages-2014/

2: Discluding CSS and shell since they don't require memory management. Python's default implementation actually has both RC and GC.

Re: Real-Time Garbage Collection Is Real

#32

Post by gkuan »

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.

There is also this paper by Bacon et al that develops a framework that shows the relationship between refcount and tracing GC (duals of each other) plus the various optimizations of the two: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.143....

Re: Real-Time Garbage Collection Is Real

#33

Post by danbruc »

userbinator wrote: post #16

our running programs may exceed the amount of space we want them to take The majority of real-time systems are the small embedded ones where both speed and size are usually highly constrained, so this doesn't look as useful as it may seem. It's well known that GC overhead decreases with increasing available memory, so the result shouldn't be so surprising. A relevant phrase I've heard is "garbage collection is free o…

It is not only useful for embed system with hard real-time constraints but may also, for example, improve server systems with (very) soft real-time constraints by reducing response time jitter due to garbage collection cycles.

Re: Real-Time Garbage Collection Is Real

#34

Post by Dewie »

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…

> , but I haven't seen a way to swap out the memory allocator in various contexts.

You mean something like this?

https://github.com/rust-lang/rfcs/pull/244

I think part of it was inspired by something similar from C++. D-lang also seems to have something like this.

Re: Real-Time Garbage Collection Is Real

#35

Post by tkellogg »

tokenrove wrote: post #7
edsiper2 wrote: post #3

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

Reminder: There are real-time allocators available, they just tend to not be used because the average case is worse.

* http://repository-of-projects.googlecode.com/svn/trunk/docum... * http://www.ijera.com/papers/Vol2_issue3/GR2311511156.pdf

Re: Real-Time Garbage Collection Is Real

#36

Post by pshc »

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.

Re: Real-Time Garbage Collection Is Real

#37

Post by AceJohnny2 »

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?

Re: Real-Time Garbage Collection Is Real

#38

Post by ezy »

Dewie wrote: post #34
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…

> , but I haven't seen a way to swap out the memory allocator in various contexts. You mean something like this? https://github.com/rust-lang/rfcs/pull/244 I think part of it was inspired by something similar from C++. D-lang also seems to have something like this.

Yup. That's excellent. Rust changes so fast, I can hardly keep up. :-)

Re: Real-Time Garbage Collection Is Real

#39

Post by Dewie »

ezy wrote: post #38
Dewie wrote: post #34

Earlier quoted context omitted.

> , but I haven't seen a way to swap out the memory allocator in various contexts. You mean something like this? https://github.com/rust-lang/rfcs/pull/244 I think part of it was inspired by something similar from C++. D-lang also seems to have something like this.

Yup. That's excellent. Rust changes so fast, I can hardly keep up. :-)

Sadly though I haven't been able to find any mention of if and when it will be realized. But the sentiment - from what I've gleaned from discussions on it - seems to be that something like that should/need to happen.

Re: Real-Time Garbage Collection Is Real

#40

Post by bad_user »

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…

Unity uses an older Mono (2.10 I believe) which has a poor GC that's not even deterministic, so you can easily suffer memory leaks. It is also not generational. Newer versions of Mono come with a much better GC.
Post reply on HN