First, the overhead of GC depends not only on the heap size, but also on the allocation rate and allocation profile. For reasonable allocation rates found in typical GUI apps, most Java GCs do extremely well having very little additional memory, like only 20% more than the live set size. There is no "twice as much" assumption anywhere in their design.
Second, manual memory managers do have their own overhead too, in form of bookkeeping (e.g. free lists) and internal fragmentation. Fragmentation can be sometimes much worse than GC memory overhead for long running applications, because GC memory overhead is typically bounded, while fragmentation is either unbounded or has extremely high upper bounds (like 10x in "fast" allocators).
There is in that the nursery collector is often a simple Cheney-style copying collector that wants two semispaces. But that's only one of the generations. There's definitely no requirement that total GC memory is double the used space.
- namespaces
- memory safe
- you don't have to type @ and [] everywhere to switch between dynamic and static worlds
As for the vm thing, there are also commercial native compilers, even though the general HNer tend not to be aware of them.
Thus giving Android developers all the fun of dealing with GC pauses. There's a lot to be said for ARC, really; I'm quit glad Apple ditched their brief experiment with ObjC GC.
> namespaces
I'll give you that one; lack of namespaces it the worst thing about ObjC.
> ... Dynamic and static worlds...
I'm not sure what you mean here; Java is a statically typed language, and does not have a 'dynamic world'. ObjC has a fo of optional dynamic typing, which is arguably modern, though also only arguably a good thing.
Because they failed to implement a GC that didn't crash all the time, as the Apple forums used to testify before ARC was touted as the best thing since sliced bread.
The wonders of mixing Objective-C libraries compiled in mixed mode.
> I'm not sure what you mean here;
The mixed nature of Objective-C.
With @ and [] one is in Smalltalk land. Without them, one is in C world.
> Java is a statically typed language, and does not have a 'dynamic world'.
Yes it has, via reflection, annotations and dynamic bytecode generation.
This is an odd and not particularly true way of looking at things. [] (for message sending), is merely some syntactic sugar for the objc_msgsnd function call.
A means of gathering the code, dump it into a series of objc_msgsnd, without doing much of real compiler work.
There are languages with Smalltalk semantics without forcing me to type @ and [] multiple times per line, a pain in non US keyboards.
id map = @{ @"my key": @123};ImmutableMap.builder().put("my key", 123).build();
Which hardly seems neater (especially in a more realistic case where you have more than one entry).
Apparently they haven't done any changes since JIT was introduced in 2.3 version. Additionally we have ART without any information whatsoever about future plans.
In the meantime it does seem likely that Java has a non-negligible performance cost. My personal worry is that fast Garbage Collectors usually assume that twice the memory is available than is used. That might put the fact that Android phones typically have more memory than Apple devices in an interesting light.