News for hackers. Stuff that matters.
Re:V8: A Tale of TurboFan by mwcampbell on Thursday March 02, 2017 @10:19AM (#13774595)
Interesting. I was under the impression that Android had more problems with RAM pressure than iOS, because Android uses tracing GC rather than reference counting. I observed that as late as the iPhone 6, the flagship iOS device had only 1 GB of RAM, whereas contemporaneous flagship Android devices had 2 or 3 GB. I guess I succumbed to the tendency to assume that Apple can do no wrong, leading to the assumption that Apple shipped with less RAM because they didn't need it, not because they were just being cheap.
Re:V8: A Tale of TurboFan by mike_hearn on Thursday March 02, 2017 @01:53PM (#13777003)
GC technically speaking can reduce the amount of RAM you need, as it can compact the heap whereas a native malloc can't. In practice this effect is hard to measure as the sorts of languages that use compacting GCs tend to be rather pointer and allocation happy, so any gain from compaction gets outweighed by other factors.

The specs of the various devices have changed over time. Android scales better: you can give it very little RAM, or a lot, and it'll make best use of it by e.g. keeping more background apps loaded at once. iOS was at least historically much less flexible about this: boosting RAM was not worth as much as in the Android space because app devs would still target older devices for quite a while and so the additional RAM would go unused, and the OS wasn't capable of using the spare for much due to the lack of multi-tasking.

Eventually Apple implemented Android-style task switching, so I don't know if that's still true. I haven't done any mobile dev for years. But I also think at some point Apple realised nobody who buys an iPhone actually cares about whether they're getting value for money or what the specs are, so they just stopped competing on that area. I mean they have never reduced the price of the iPhone once, right? Despite the huge fall in underlying component prices over the years. They could ship a device with 128mb of RAM and if it did the same thing as the iPhone 4 people would still buy it, simply because they see themselves as iPhone users and not "smartphone users.

Re:V8: A Tale of TurboFan by mwcampbell on Thursday March 02, 2017 @05:49PM (#13779055)
It goes to show that several factors influence the performance, memory usage, and real hardware requirements of a platform. I'll gladly admit that my original, simplistic assumptions were wrong.

ObjC, as typically written (i.e. more object-oriented than C), is also pointer and allocation heavy. so that might make compaction more of a benefit for Android. I wonder what proportion of memory in a typical Android application process is on the C heap rather than the garbage-collected, compacted heap. For example, where does image data usually end up?

To throw in another complication, are there any significant problems that come with layering a garbage-collected runtime on top of a high-level framework based on C heap allocation and reference counting? That's what Xamarin, React Native, and AOT Java runtimes (e.g. Multi OS Engine) do on iOS, and what .NET (even .NET Native) does on UWP. Or how about two garbage-collected runtimes in one process, e.g. Xamarin and React Native on Android?

Re:V8: A Tale of TurboFan by pjmlp on Thursday March 02, 2017 @12:28PM (#13776057)
Google did lots of work to fit Android on 512MB devices, also modern Android does use a parallel concurrent GC with just one pause. They also made the JNI stricter, in order to allow compactation on future versions.

Windows Phone .NET runtime also uses tracing GC, although the underlying UWP APIs are COM based.

Re:V8: A Tale of TurboFan by bitmapbrother on Thursday March 02, 2017 @08:04PM (#13779913)
An interesting watch:

Does Android use more memory than iOS?

https://www.youtube.com/watch?v=lCFpgknkqRE

Re:V8: A Tale of TurboFan by FullyFunctional on Saturday March 04, 2017 @02:16AM (#13789770)
His conclusion overlooks the key issue: memory burns power! This is why Apple tries to put as little in as possible.