5 ms·

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

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.

rohan404 12y ago
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.
- on_and_off 12y ago
  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).
  - rohan404 12y ago
    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
    - kuschku 12y ago
      On Android you should definitely load the images Async and not load them within the draw call.
      - rohan404 12y ago
        Even loaded asynchronously, the calls for allocation still cause lag. Unless I am doing something incorrectly?
        on_and_off 12y ago
        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.
- izacus 12y ago
  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.
rtpg 12y ago
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.
- swartkrans 12y ago
  > 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.
  - taspeotis 12y ago
    > 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-profiling https://developer.chrome.com/devtools/docs/javascript-memory...
  - rtpg 12y ago
    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.
  - pjmlp 12y ago
    Really?! Mozilla even has a memory leaks tooling tracking page: https://developer.mozilla.org/en-US/docs/Mozilla/Performance 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.
pjmlp 12y ago
> 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.
agumonkey 12y ago
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.
- sz4kerto 12y ago
  > `malloc` isn't free I see what you did there. :)
  - agumonkey 12y ago
    Ha. I wish, but it was too early in the morning for me to generate such puns.
  - wabbawabbe 12y ago
    What's the pun ?
    - jimktrains2 12y ago
      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).
deleted 12y ago
[deleted]
lucian1900 12y ago
Even when it was created, Dalvik had a sub-par GC. A bad GC implementation doesn't say much about GC in general.
- InclinedPlane 12y ago
  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.
  - lucian1900 12y ago
    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.
    - pjmlp 12y ago
      I read somewhere that the Dalvik original team is no longer at Google. Not sure if this is true.
    - InclinedPlane 12y ago
      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.

rohan404 12y ago

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.

on_and_off 12y ago
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).
- rohan404 12y ago
  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
  - kuschku 12y ago
    On Android you should definitely load the images Async and not load them within the draw call.
    - rohan404 12y ago
      Even loaded asynchronously, the calls for allocation still cause lag. Unless I am doing something incorrectly?
      - on_and_off 12y ago
        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.
izacus 12y ago
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.

rtpg 12y ago

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.

swartkrans 12y ago
> 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.
- taspeotis 12y ago
  > 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-profiling https://developer.chrome.com/devtools/docs/javascript-memory...
- rtpg 12y ago
  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.
- pjmlp 12y ago
  Really?! Mozilla even has a memory leaks tooling tracking page: https://developer.mozilla.org/en-US/docs/Mozilla/Performance 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.

pjmlp 12y ago

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

agumonkey 12y ago

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.

sz4kerto 12y ago
> `malloc` isn't free I see what you did there. :)
- agumonkey 12y ago
  Ha. I wish, but it was too early in the morning for me to generate such puns.
- wabbawabbe 12y ago
  What's the pun ?
  - jimktrains2 12y ago
    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).

deleted 12y ago

[deleted]

lucian1900 12y ago

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

InclinedPlane 12y ago
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.
- lucian1900 12y ago
  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.
  - pjmlp 12y ago
    I read somewhere that the Dalvik original team is no longer at Google. Not sure if this is true.
  - InclinedPlane 12y ago
    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.