Hacker News Reader

Comment by frozenport | Hacker News Reader

This article is a great reminder that garbage collection should not be the default strategy as it is hard to get right, Dalvik is almost a decade old, and that it introduces performance issues which are not transparent to the programmer. Indeed these second long delays have rendered Android hardware second rate.

View on HN

betweeen having GC pauses and having memory leak continuously (and buffer overflow issues which become security issues) I'll take GC pauses.

Time has proven again and again that humans are really bad at memory management and having raw access to memory is something that needs to be justified on a case by case basis.

> Time has proven again and again that humans are really bad at memory management

Well until AI write garbage collectors I'm not sure I see how your comment doesn't also apply to them. And lots of great software manages memory quite fine, like that browser you used to write your comment and the operating system it runs on, so not sure the use of "proven" is appropriate in your comment.

> And lots of great software manages memory quite fine, like that browser you used to write your comment

Which bit of the browser are you talking about? Garbage collection is used extensively during the execution of JavaScript in a lot of browsers. For example, Chrome [1].

[1] https://developer.chrome.com/devtools/docs/javascript-memory...

I think we've all used software that suffers from some pretty intense memory leaks ( including older versions of firefox!), and garbage collectors can be "good enough" for a huge amount of applications.

Most applications are _not_ games or web browsers, but enterprise-y CRUD applications.

I'm fine with having the ability to turn that off for specific things, but it should be made as inconvenient as possible to avoid the "Can't have GC pauses in my todo list" usecase.

Really?! Mozilla even has a memory leaks tooling tracking page:

https://developer.mozilla.org/en-US/docs/Mozilla/Performance

And are making Servo in Rust, which uses compiler dataflows form memory management.

Apple has added ARC to Objective-C and Swift.

Microsoft uses GC in .NET, ARC in C++/CX.

Modern C++ favors RC.

They all seem to think manual memory management is to be avoided.

Rust shows that "between having GC pauses and having memory leak continuously (and buffer overflow issues which become security issues) I'll take GC pauses" is a false dichotomy, however.

Yes, I am following it quite closely.

However it does place a bit of cognitive burden, but last version already improved it.

Rust is one of the coolest things in programming at the moment, but if you have to invent your own programming language to cut this gordian knot, then it's not really a false dichotomy for most practical purposes. And it'll stay a genuine dichomoty until Rust (or something like it) is a mainstream choice.

I'm glad for the advances in Rust. My comment was meant in the context of the current state of the art (Java/C++ like). If we move forward enough the GC questions could be a thing of the past.

> Modern C++ favors RC.

Does it? I was under the impression that the order of preference (from most preferred to least) is something like:

  - plain values (i.e. no pointers)
  - references
  - unique_ptr
  - shared_ptr
  - raw pointers

Raw pointers is the last item on your list after RC pointers.

From this response, I guess that maybe you were meaning C++ favours RC compared to manual memory management, and were not saying that it is the globally preferred option, but this differs to everything else in your list: the others are the main/preferred strategy in those languages/libraries.

> I guess that maybe you were meaning C++ favours RC compared to manual memory management,

Yes.

> the others are the main/preferred strategy in those languages/libraries.

While true, manual memory management is still possible, but should be left for the 1% cases that really benefit from it.

Presumably the humans writing popular garbage collectors are significantly better at memory management than the average programmer. You wouldn't say that humans shouldn't go to doctors until there are AI doctors.

Memory management is obscure. `malloc` isn't free either, and gc has been shown to allow some 'out-of-order' benefits. It's a different way of thinking altogether. Right now libart's AOT makes launching overhead very small and tight loops faster but sometimes it introduces lags that I didn't have under Dalvik.

> `malloc` isn't free

I see what you did there. :)

Ha. I wish, but it was too early in the morning for me to generate such puns.

What's the pun ?

free() is the "counterpart" to malloc(). malloc() lets you allocate memory for your use; free() returns that memory back to the system.

The original posters meaning was that "malloc() has non-trivial execution costs", but the other meaning is, tautologically, malloc is the "complement" of free (think true is not false).

> This article is a great reminder that garbage collection should not be the default strategy as it is hard to get right,

You are forgetting that Dalvik hasn't been touched since Android 2.3.

Of course, not much could be expected from it.

Even when it was created, Dalvik had a sub-par GC. A bad GC implementation doesn't say much about GC in general.

It does, actually. The fact that good GC implementations are rare means that GC in general is necessarily subject to poor GC implementations and all the problems that go with them. That may change over the coming years but the fact that it's taken nearly three decades to get the state-of-the-industry in GCs to an acceptable level shows what a struggle it's been.

It's a bit like the folks who say that dynamic languages can be just as fast as compiled languages. Perhaps eventually, but in the here and now in the typical case that claim misses the mark by orders of magnitude.

Not using the state of the art will give a bad impression, yes.

There are plenty of very fast dynamic language runtimes: LuaJIT, PyPy, Spidermonkey, V8, SBCL, etc. They're all competitive with JVMs and some are consistently faster.

Dalvik avoided the state of the art on purpose, for some reason. It didn't even have a JIT by default until Android 2!

There are quite a few decent GCs out there, Dalvik's merely had almost no work put into it.

I read somewhere that the Dalvik original team is no longer at Google. Not sure if this is true.

I think you misunderstood the point I was trying to make.

Sure, there are good GCs out there, but good GCs are harder than many GC proponents make out.

Take the top 100 most heavily used applications or platforms that rely on garbage collection. What fraction of them actually use decent GC implementations?

Also, you seemingly misread my other point about dynamic language runtimes, I wasn't comparing them to JVMs, I was comparing them to compiled code written in lower level systems languages (like C/C++). V8 may be fast, but it's not as fast as compiled code, yet. There's still a huge gap between theory and practice there.

It was pretty ridiculous, even on some of the most powerful hardware out there I still found animations to lag from time to time due to the GC_FOR_ALLOC calls! Ended up with a bunch of hacks to try to work around the issue, but none fully resolved it.

If animations lag because of allocations, then you are allocating too many objects.. The most common cause is object allocation in a critical part like a draw call (or view binding).

This is true, but for operations like loading images from disk for example, this is unavoidable. The best you can do is reuse memory instead of allocating whenever possible

On Android you should definitely load the images Async and not load them within the draw call.

Even loaded asynchronously, the calls for allocation still cause lag. Unless I am doing something incorrectly?

You can use inBitmap in order to reuse bitmap instances instead of of allocating new objects. If it fits your use-case, Glide is a very modular lib that implements inBitmap. It is true that you will always have to create some objects though. For example with Glide, a DataFetcher is created with each new image request. You should do your best to keep it at a minimum though, with a focus on creating heavy objects only when it is absolutely necessary.

Other than that, lag can come from many things, so if you lag without GC, the only solution is to profile that part of your app.

No matter what language, allocations are expensive. Your stuttering would appear in C++, ObjC or Java. Don't mistake slow allocations for a GC issue.

Reply on news.ycombinator.com