

Why 1GB RAM in iOS Gives at Par Performance with 3GB Android Phone? - sourcex
http://www.quora.com/How-come-the-iPhones-1-GB-RAM-is-touted-to-be-able-to-compete-with-more-than-2-GB-RAM-of-Android-phones/answers/7061202?share=1

======
vardump
I think Java's issue is not really due to garbage collection directly, but
overuse of references (pointers) leading to very complicated object graphs.

This in turn leads to a lot of pointer chasing, cache thrashing and typically
significantly higher memory requirements. It's sad how bad reputation this has
"earned" for garbage collection in general.

Even with just a few CPU cores, if you tried to emulate a similar number of
object pointers by using reference counting instead of garbage collection, I
believe it'd be at least by an _order of magnitude slower_ than modern GC
algorithms. With tens of CPU cores, reference counting would get almost no
actual work done. Garbage collection would outperform it by a very large
margin.

Manual memory management wouldn't fare much better, because memory allocation
is glacial: "malloc" (and often also "free") are _very_ slow. Allocators need
to traverse a complicated data structure to find a suitable free memory block
and to mark it used. Fortunately memory allocation algorithms can at least
scale with number of CPU cores.

Reference counting is problematic with more than one CPU core. If multiple
cores can access the same reference counted object, naive reference counting
very quickly saturates CPU core interconnect with cache coherence traffic.
Every time a reference count is increased (retained/reserved/locked) or
decreased (released), an atomic operation is required, all cores must have
same value in their local caches. The reference count changes need to be
communicated to _all_ other CPU cores [1]. This performance penalty can be
partially worked around by minimizing number of reference count alterations
and by using hacks on top of the simple case, but at cost of complexity and
reduction of safety.

In Java, you can't have an array of Objects, for non-elementary types you get
an array of references (pointers) instead, where each array element carries
overhead of java.lang.Object. The number of pointers is gigantic in pretty
much any JVM heap. This is very bad especially for small objects, which
unfortunately tend to dominate nearly any heap.

You can of course get around this by "rotating" arrays of Objects. No array of
Objects, but Object of arrays. Each semantic Object field becomes an
elementary type array in a holder Object.

This fixes performance and memory consumption at cost of flexibility, code
size and readability.

Garbage collection extends the object lifetimes and scales linearly with
number of CPU cores, but needs [periodic] housekeeping. Reference counting
keeps object lifetimes short, but is unsafe with multiple CPU cores or needs
slow atomic operations that result expensive inter-core cache coherence
traffic, making it ultimately scale badly.

There's no silver bullet.

[1]: Real cache coherence protocols are quite a bit more complicated than
that, see
[http://en.wikipedia.org/wiki/Cache_coherence](http://en.wikipedia.org/wiki/Cache_coherence)

~~~
geon
> You can't have an array of Objects, for non-elementary types you get an
> array of references (pointers) instead, where each array element carries
> overhead of java.lang.Object.

Isn't that true in Objective C as well, though? Or does NSObject have much
less overhead?

~~~
informatimago
Indeed. The difference may be that classes in the iOS frameworks are general
more coarse grained than classes in the Android frameworks.

When you only need one class to do something in iOS (and MacOSX), you might
need ten classes in Android (and other Java frameworks).

For example, compare the number of classes to parse xml on iOS (one class:
NSXMLParser), vs. the number of packages and classes to parse xml on Android:
(javax.xml.datatype.DatatypeConstants,
javax.xml.datatype.DatatypeConstants.Field,
javax.xml.datatype.DatatypeFactory, javax.xml.datatype.Duration,
javax.xml.datatype.XMLGregorianCalendar, javax.xml.namespace.NamespaceContext,
javax.xml.parsers.DocumentBuilder, javax.xml.parsers.DocumentFactory,
javax.xml.parsers.SAXParser, javax.xml.parsers.SAXParserFactory,
javax.xml.parsers.ParserConfigurationException,
javax.xml.parsers.FactoryConfigurationError, (I'll skip all the
javax.xml.transform packages and classes, since assumedly they wouldn't be
used to read xml), javax.xml.validation.Schema,
javax.xml.validation.SchemaFactory, javax.xml.validation.SchemaFactoryLoader,
javax.xml.validation.TypeInfoProvider, javax.xml.validation.Validator,
javax.xml.validation.ValidatorHandler, javax.xml.xpath.XPath,
javax.xml.xpath.XPathExpression, javax.xml.xpath.XPathFunction,
javax.xml.xpath.XPathFunctionResolver, javax.xml.xpath.XPathVariableResolver,
javax.xml.xpath.XPathConstants, javax.xml.xpath.XPathFactory,
javax.xml.xpath.XPathException, javax.xml.xpath.XPathExpressionException,
javax.xml.xpath.XPathFactoryConfigurationException,
javax.xml.xpath.XPathFunctionException, amongst a lot of other classes).

------
ParvusPonte
Better memory usage due to the (BSD-like) kernel, vs Linux could be one of the
factors.

"My server earlier used to consume over 1 GB of memory for running PHP, MySQL
and Nginx. Now, it doesn’t even touch 500 MB! It’s always less than 500 MB.
Everything is just same, configuration, etc. Only OS changed."
[http://nileshgr.com/2013/06/07/the-move-from-linux-to-
freebs...](http://nileshgr.com/2013/06/07/the-move-from-linux-to-freebsd)

Slightly off topic but I really wish mainstream VPS providers start adopting
FreeBSD, perhaps [http://labs.online.net/](http://labs.online.net/) can spark
that change, I'd move from Digital Ocean in a heart beat!

~~~
informatimago
Well, MacOSX and iOS don't have a BSD kernel (or even a BSD-like kernel) at
all. They have a Mach kernel. They have howewver, a BSD-like userland and
kernel personality. But I guess we can assume that the Mach kernel is also
more frugal than Linux. In any case, AFAICS, Apple takes some care about this,
because of the performance and user experience consequences.

------
vlad
Besides reasons mentioned in this topic, Apple's desktop and mobile operating
systems feature memory compression and other algorithms to save memory and
battery life for the last year, since Mavericks and iOS 7.

[http://www.umass.edu/newsoffice/article/key-features-
apple%E...](http://www.umass.edu/newsoffice/article/key-features-
apple%E2%80%99s-new-operating-system)

------
barrystaes
There is only 1GB of ram in iPads? This explains why the browser keeps
crashing when i keep 20 tabs open.. jeez!

------
paines
BSD-ish vs Linux Kernel ?

------
dozzie
Simple: because of Java.

~~~
informatimago
You could (try to) write coarser grained classes in Java too (granted, with
static typing, it may be harder to do).

