
Real-Time Garbage Collection Is Real - luu
http://michaelrbernste.in/2013/06/03/real-time-garbage-collection-is-real.html
======
userbinator
_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 only if memory is worth nothing."

Limiting the amount of work the GC can do also means that some quite subtle
bugs can arise from exceeding the "allocation rate" that it can handle, which
is something that might not be as easy to determine in GC-using code.

 _but not the amount of space that we estimate they could possibly take_

I think it's a bad sign when the word "estimate" is used in talking about a
real-time system... this is an area of guarantees and proofs, not educated
guesses.

~~~
danbruc
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.

------
ajross
> 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 different definition for
"real" than most of us use.

~~~
pjmlp
Why waiting?

[http://www.atego.com/de/products/atego-
perc/](http://www.atego.com/de/products/atego-perc/)

[https://www.aicas.com/cms/en/JamaicaVM](https://www.aicas.com/cms/en/JamaicaVM)

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

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

~~~
ezy
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.).

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

~~~
ezy
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.

------
gaze
I'd love to try implementing C4 or Metronome or Staccato, and I have some
interesting applications for them too. The problem is all this development is
sponsored by Azul, Microsoft, and IBM. All the Bacon papers have corresponding
IBM patents, all the Petrank papers have corresponding Microsoft patents. It
sucks. Even if I come up with something new, it'll look like a slight variant
on something someone else has done and I don't want to get sued!

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

~~~
m0th87
> 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/](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.

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

Yet GC solves 10% of the problem that RAII solves. Tbh I would call them
"similar". GC has the advantage of being much more tolerant of sloppy
programming, but if you compare the complexity of GC with the complexity of
RAII, I'd say RAII has a clear advantage.

~~~
pjmlp
Most RAII use cases can be taken with using/with/try/lambdas

------
chrismorgan
This site could be improved for narrower viewports by changing the .site width
to max-width. Combine with something like `padding: 0 0.5em;` for better
results.

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

~~~
AceJohnny2
what's virtual reality in this context?

~~~
pshc
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.

~~~
pjmlp
I know of missile control systems done in Real Time Java.

Just one example,

[http://www.atego.com/pressreleases/pressitem/aonix-perc-
ultr...](http://www.atego.com/pressreleases/pressitem/aonix-perc-ultra-
virtual-machine-passes-muster-on-modernized-guided-missile)

Better no GC jitter....

------
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](http://en.wikipedia.org/wiki/Region-
based_memory_management)

------
edsiper2
man 3 free

~~~
tokenrove
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.

~~~
tkellogg
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://repository-of-projects.googlecode.com/svn/trunk/document/c_c++/memory/TLSF/Two-Level%20Segregated%20Fit.pdf) * [http://www.ijera.com/papers/Vol2_issue3/GR2311511156.pdf](http://www.ijera.com/papers/Vol2_issue3/GR2311511156.pdf)

