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

51–60 of 62 posts

Re: Real-Time Garbage Collection Is Real

#51

Post by bitwize »

bad_user wrote: post #50
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.

Apple did introduce optional GC into its Mac OS X runtime. It received little uptake and was subsequently removed because Apple and its developer base realized ARC was the better solution.

If your code is leaking because of reference cycles, maybe that's a problem with your code, not ARC. (I.e., structure your data as an acyclic graph or tree and/or use weak references rather than expecting the runtime to compensate for your sloppiness.)

Re: Real-Time Garbage Collection Is Real

#52

Post by kibwen »

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.

The Rust developers will be the first to tell you that if you can get away with writing your application in a GC'd language, you probably should. Garbage collectors really are fantastic pieces of technology if you aren't heavily bound by memory or speed constraints.

Rust exists to fulfill a need in the domains where GCs are not acceptable, not to obviate GCs entirely. It merely offers the industry a viable alternative to the typical ravages of rampant manual memory mismanagement.

Re: Real-Time Garbage Collection Is Real

#53

Post by gjm11 »

bitwize wrote: post #51
bad_user wrote: post #50

Earlier quoted context omitted.

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.

Apple did introduce optional GC into its Mac OS X runtime. It received little uptake and was subsequently removed because Apple and its developer base realized ARC was the better solution. If your code is leaking because of reference cycles, maybe that's a problem with your code, not ARC. (I.e., structure your data as an acyclic graph or tree and/or use weak references rather than expecting the runtime to compensate…

There are plenty of situations in which reference cycles would be perfectly sensible (and not at all "sloppy") ways to organize your data if it weren't for reference counting.

For example: suppose you are writing some code that analyses a strategy game. You have (let's say) an object representing a position in the game; each position object has references to the positions you can move from there to. If repeated positions are possible, then you have a reference cycle.

For example: you have a tree-like structure in which things contain other things. It's convenient for each thing to have a reference to its parent, and for each thing to have references to its children. Boom, reference cycles everywhere.

For example: you are implementing a programming language that has closures. So each closure object has a reference to its lexical environment, and some of the things in that environment may themselves be closures defined in that environment. Reference cycles. (The same happens if you have classes, and methods have references to the class where they're defined.)

Of course, all these things can be avoided. Often you can pick some subset of the references (e.g., the parent pointers) and make them weak references, or you can restructure your code to make some of the references go away (e.g., positions don't have references to their successors, they have methods/functions for generating them). But the only reason to do those things is that you need to avoid reference cycles. Refcounting isn't (in these cases) kindly helping you improve your code by forcing you to avoid sloppy constructs; it's taking what would otherwise be perfectly sensible code, making it sloppy, and then forcing you to do something else to avoid the resulting memory leaks.

Re: Real-Time Garbage Collection Is Real

#54

Post by mamcx »

psykotic wrote: post #27
mamcx wrote: post #25

Earlier quoted context omitted.

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 an…

So, if I design a language, how design it well? I suspect is easy to kill all values (ints, str, etc) and arrays/list of it. But how know what is a "don't own any heap-allocated subobject" (sorry to ask if this is obvious, I have not deep experience in this matters)?

Is not circular references the real problem? And what when the object reference a resource like a file/handle/database/etc?

So, could be good idea to mark objects like this (maybe in separated areas of memory?):

Instant kill: Ints, Strs, Bools, Array of all of this

Safe destructors: If it hold a resource (file, handle)

But don't know what to do for objects like Customer.Orders = List[Order1.Customer]

Re: Real-Time Garbage Collection Is Real

#55

Post by waps »

m0th87 wrote: post #31
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…

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

Re: Real-Time Garbage Collection Is Real

#56

Post by pjmlp »

waps wrote: post #55
m0th87 wrote: post #31

Earlier quoted context omitted.

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

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

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

Re: Real-Time Garbage Collection Is Real

#57

Post by pjmlp »

bitwize wrote: post #51
bad_user wrote: post #50

Earlier quoted context omitted.

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.

Apple did introduce optional GC into its Mac OS X runtime. It received little uptake and was subsequently removed because Apple and its developer base realized ARC was the better solution. If your code is leaking because of reference cycles, maybe that's a problem with your code, not ARC. (I.e., structure your data as an acyclic graph or tree and/or use weak references rather than expecting the runtime to compensate…

> Apple did introduce optional GC into its Mac OS X runtime. It received little uptake and was subsequently removed because Apple and its developer base realized ARC was the better solution.

You are telling the story wrong.

The reality was the the GC never worked properly, specially when mixing frameworks compiled with and without GC, leading to core dumps.

There there was a list of corner cases causes by having C as part of Objective-C.

Apple did not introduce ARC because it was little uptake.

They introduced because the GC never worked properly, so devs had better things to do than GC core dumps and ARC is a better approach to the Objective-C semantics.

Re: Real-Time Garbage Collection Is Real

#58

Post by pjmlp »

bad_user wrote: post #47
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.

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…

> Rust is the only language (I know) ...

Have a look at Cyclone, ATS and ParaSail.

Re: Real-Time Garbage Collection Is Real

#59

Post by pjmlp »

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.

> the opposition isn't just Apple anymore, though they dealt the first blow.

Funny how the technical inability to write a decent GC for Objective-C made them the hero of ARC.

Re: Real-Time Garbage Collection Is Real

#60

Post by pjmlp »

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…

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

Just one example,

http://www.atego.com/pressreleases/pressitem/aonix-perc-ultr...

Better no GC jitter....

Post reply on HN