3 ms·

It's still amazing to me how powerful these devices have become that you can put a GC on a mobile platform, especially considering how sensitive users would be

It's still amazing to me how powerful these devices have become that you can put a GC on a mobile platform, especially considering how sensitive users would be to GC stalls causing unresponsive user interfaces.

samstokes 16y ago
I'm pretty sure modern garbage collectors don't have that "stop the world" behaviour that causes unresponsiveness. And tens of millions of J2ME-capable phones have been running garbage collectors for years. (And while J2ME has a reputation for slowness, that's mostly about startup time, and anyway it's largely due to bad coding rather than the runtime being inherently slow. Opera Mini and the J2ME version of Google Maps are both more responsive than many "native" apps.)
- ori_b 16y ago
  Many of them do have stop-the-world GC. A well implemented stop the world GC allows higher throughput, at the cost of increased latency. This is especially the case when provably-local allocations can be put onto a thread-local heap, and you only do stop-the-thread GC on those. So, in the absolute sense, stop-the-world GC overhead is lower than incremental, low-latency GC. But yes, we have GC that is fairly responsive these days, too, for when throughput isn't the driving concern.
stcredzero 16y ago
It's still amazing to me how powerful these devices have become that you can put a GC on a mobile platform Really? Colleagues have told me of applications using GC that ran on 486 with good performance. The popular notions of what dynamic languages and GC are like are literally decades out of whack. This is a self perpetuating phenomenon, which is why you can have popular languages that are between 1 and 2 orders of magnitude slower than they should be. (Outdated GC being a prominent factor.)
- dschobel 16y ago
  I remember the GC stalls being quite apparent for swing applications which I wrote in undergrad back in the 2000 to 2002 time frame (so it must have been java 1.3). Highly responsive UI and relatively low system memory (256MB on the G1) just strikes as quite the feat on top of a GC language. Although you're right, I may just be dating myself.
  - stcredzero 16y ago
    Back in 2000, Java VMs were still lagging behind Smalltalk VMs, especially in real-world performance.

samstokes 16y ago

I'm pretty sure modern garbage collectors don't have that "stop the world" behaviour that causes unresponsiveness. And tens of millions of J2ME-capable phones have been running garbage collectors for years. (And while J2ME has a reputation for slowness, that's mostly about startup time, and anyway it's largely due to bad coding rather than the runtime being inherently slow. Opera Mini and the J2ME version of Google Maps are both more responsive than many "native" apps.)

ori_b 16y ago
Many of them do have stop-the-world GC. A well implemented stop the world GC allows higher throughput, at the cost of increased latency. This is especially the case when provably-local allocations can be put onto a thread-local heap, and you only do stop-the-thread GC on those. So, in the absolute sense, stop-the-world GC overhead is lower than incremental, low-latency GC. But yes, we have GC that is fairly responsive these days, too, for when throughput isn't the driving concern.

stcredzero 16y ago

It's still amazing to me how powerful these devices have become that you can put a GC on a mobile platform Really? Colleagues have told me of applications using GC that ran on 486 with good performance. The popular notions of what dynamic languages and GC are like are literally decades out of whack. This is a self perpetuating phenomenon, which is why you can have popular languages that are between 1 and 2 orders of magnitude slower than they should be. (Outdated GC being a prominent factor.)

dschobel 16y ago
I remember the GC stalls being quite apparent for swing applications which I wrote in undergrad back in the 2000 to 2002 time frame (so it must have been java 1.3). Highly responsive UI and relatively low system memory (256MB on the G1) just strikes as quite the feat on top of a GC language. Although you're right, I may just be dating myself.
- stcredzero 16y ago
  Back in 2000, Java VMs were still lagging behind Smalltalk VMs, especially in real-world performance.