5 ms·

IMHO, they want to get everything that has a UI as responsive as possible. GC in theory is a good feature but it does not guarantee that constant time is used

by ttflee 12y ago

IMHO, they want to get everything that has a UI as responsive as possible. GC in theory is a good feature but it does not guarantee that constant time is used for each mark-and-sweep cycle. And together with multithreading that means uncertainty for rendering every frame of video, which is done in the main thread of an App 60 times per second. And for modern system, anything you see on screen is part of this rendering. Try to think about how could memory shared by main thread and a background thread be GCed. It could turn out to be: halting the process for GC, retaining some memory forever, or implementing some complicated algorithm that is too difficult to debug/maintain.

oconnor0 12y ago
That can be resolved with a different GC.
- ttflee 12y ago
  Yes, I have heard of some algorithms that consume a lot more memory to balance timing. E.g.: http://michaelrbernste.in/2013/06/03/real-time-garbage-collection-is-real.html http://michaelrbernste.in/2013/06/03/real-time-garbage-colle...
- fidotron 12y ago
  Not really. I've had to deploy lots of soft real time apps on GCed environments over the years, and it's always a problem. You can work around it with things like object pools, but some library or API will assume that the GC is OK and will be quietly spitting out objects continuously which will lead to a GC pause. It's worth pointing out the Android devs finally started noticing this for Lollipop (probably due to their animations) and the API now has lots of places where it passes Java primitives instead of objects, which is the distinction between passing by value and by reference. Even if you're in C++ modern compilers can only make the most out of it if you pass by value, as this enables all sorts of other optimisations to kick in. The key benefit of reference counting is it's predictable. Real time systems are also not strictly the lowest latency, they are defined by predictability. This becomes a preoccupation with minimising your worst case scenario.
  - krschultz 12y ago
    It's worth pointing out the Android devs finally started noticing this for Lollipop (probably due to their animations) and the API now has lots of places where it passes Java primitives instead of objects, which is the distinction between passing by value and by reference. This is simply not true. The API has always been heavily based on Java primitives. They didn't even use enums in the older APIs, preferring instead int constants. (I hate that one personally). GC pauses have always been a point of focus for the Android platform.
    - fidotron 12y ago
      For example: http://developer.android.com/reference/android/graphics/Canvas.html http://developer.android.com/reference/android/graphics/Canv... Notice the introduction of methods with API level 21 that recreate existing functionality without RectF objects being allocated. Touch events, for example, still spit ludicrous amounts of crap on to the heap. All this is why the low latency audio is via the NDK as it's basically impossible to write Android apps which do not pause the managed threads at some point. Oddly this is stuff the J2ME people got right from day one.
      - pjmlp 12y ago
        J2ME got some bad naming due to the firware problems that OEMs brought to the platform, but Android is becoming worse than it.
      - MichaelGG 12y ago
        That's terribly ugly. Can they not do escape analysis or something to avoid allocations in obvious places? Or only allocate when the value is moved off the stack? Doesn't Android use a different flavor of Java anyways, allowing them to make these changes?
        mike_hearn 12y ago
        Yes, it's possible in theory, but Dalvik/ART don't do it. HotSpot does some escape analysis and the Graal compiler for HotSpot does a much more advanced form called partial escape analysis, which is pretty close to ideal if you have aggressive enough inlining. The problem Google has is that Dalvik wasn't written all that well originally. It had problems with deadlocking due to lock cycles and was sort of a mishmash of C and basic C++. But then again it was basically written by one guy under tight time pressure, so we can give them a break. ART was a from scratch rewrite that moved to AOT compilation with bits of JITC, amongst other things. But ART is quite new. So it doesn't have most of the advanced stuff that HotSpot got in the past 20 years.

by ttflee 12y ago

oconnor0 12y ago

That can be resolved with a different GC.

ttflee 12y ago
Yes, I have heard of some algorithms that consume a lot more memory to balance timing. E.g.: http://michaelrbernste.in/2013/06/03/real-time-garbage-collection-is-real.html http://michaelrbernste.in/2013/06/03/real-time-garbage-colle...
fidotron 12y ago
Not really. I've had to deploy lots of soft real time apps on GCed environments over the years, and it's always a problem. You can work around it with things like object pools, but some library or API will assume that the GC is OK and will be quietly spitting out objects continuously which will lead to a GC pause. It's worth pointing out the Android devs finally started noticing this for Lollipop (probably due to their animations) and the API now has lots of places where it passes Java primitives instead of objects, which is the distinction between passing by value and by reference. Even if you're in C++ modern compilers can only make the most out of it if you pass by value, as this enables all sorts of other optimisations to kick in. The key benefit of reference counting is it's predictable. Real time systems are also not strictly the lowest latency, they are defined by predictability. This becomes a preoccupation with minimising your worst case scenario.
- krschultz 12y ago
  It's worth pointing out the Android devs finally started noticing this for Lollipop (probably due to their animations) and the API now has lots of places where it passes Java primitives instead of objects, which is the distinction between passing by value and by reference. This is simply not true. The API has always been heavily based on Java primitives. They didn't even use enums in the older APIs, preferring instead int constants. (I hate that one personally). GC pauses have always been a point of focus for the Android platform.
  - fidotron 12y ago
    For example: http://developer.android.com/reference/android/graphics/Canvas.html http://developer.android.com/reference/android/graphics/Canv... Notice the introduction of methods with API level 21 that recreate existing functionality without RectF objects being allocated. Touch events, for example, still spit ludicrous amounts of crap on to the heap. All this is why the low latency audio is via the NDK as it's basically impossible to write Android apps which do not pause the managed threads at some point. Oddly this is stuff the J2ME people got right from day one.
    - pjmlp 12y ago
      J2ME got some bad naming due to the firware problems that OEMs brought to the platform, but Android is becoming worse than it.
    - MichaelGG 12y ago
      That's terribly ugly. Can they not do escape analysis or something to avoid allocations in obvious places? Or only allocate when the value is moved off the stack? Doesn't Android use a different flavor of Java anyways, allowing them to make these changes?
      - mike_hearn 12y ago
        Yes, it's possible in theory, but Dalvik/ART don't do it. HotSpot does some escape analysis and the Graal compiler for HotSpot does a much more advanced form called partial escape analysis, which is pretty close to ideal if you have aggressive enough inlining. The problem Google has is that Dalvik wasn't written all that well originally. It had problems with deadlocking due to lock cycles and was sort of a mishmash of C and basic C++. But then again it was basically written by one guy under tight time pressure, so we can give them a break. ART was a from scratch rewrite that moved to AOT compilation with bits of JITC, amongst other things. But ART is quite new. So it doesn't have most of the advanced stuff that HotSpot got in the past 20 years.