Is ARC really a win over non-refcounted GC + escape analysis? Full manual control over stack vs heap allocations and lifetime, I get, especially for games. But reference counting is not deterministic, and can also generate pauses.
@Override has been in Java since Java 5.
Also, LLVM static analyze is so good at figuring out your code path that it could effectively retain and release your memory for you.
Cyclic reference is its only flaw but its something that can easily solved through programmer awareness.
ARC may be less likely to get memory paused on release, but ARC doesn't compact free memory, and therefore fragmentation can cause object allocations (malloc) to become more expensive, possibly leading to pauses.
If you use non-copying GC that doesn't compact (ARC doesn't compact), then there are low pause GC algorithms out there that give pretty good bounds (e.g. 5ms pause).
I'd like to see actual benchmarks of both ARC and say, mark-and-sweep on a mobile device rather than speculation and opinion, and both benchmarks must get the same static compilation treatment. That is, if escape analysis tells you that the lifetime of the object is bounded by the current stack frame, then allocate it on the stack, and don't penalize the non-reference-counted GC by allocating 100% of everything on the heap.
A fair few years ago I worked in the murky world of J2ME games, and a common pattern was byte[] _variables = new byte[1024] so you could ensure there were no GC pauses.
That's not the same as ARC, though. The Java equivalent to ARC would be something like having an array of volatile reference counts to go with your variables and fiddling with those at most accesses.
It's not like tons of games haven't been shipped with non ref-count GC. Minecraft being the most famous, but games on Unity3D/Mono can have non-ref count GC. Lua is shipped in tons of game engines and uses classic GC.
Regardless of whether you are using automatic GC, or if you are using malloc/free, you can't write a high performance game without carefully working around memory issues. Even C/C++ games like Max Payne have shipped with frame hiccups caused by poor malloc/free behavior that had to be fixed with custom allocators.
If you're writing a game, you have to pay attention to what you're doing. But do non-framrate limited games and regular apps need ref-count GC? I suggest no, they do not.
Practically the first piece of advice usually given when someone asks "how do I make my Android app non-laggy" is to avoid allocation wherever possible; even a single frame drop due to a GC pause when the user is scrolling a list, say, can be noticeable.
Low pause GC is possible. See http://openjdk.java.net/jeps/189 or Zing/Azul (absolutely pauseless GC or so they claim)
What's FirefoxOS doing for it's GC?
This doesn't compile with Swift:
class A {
func foo() {
}
}
class B : A {
func foo() {
}
}interface Foo { void foo(); }
class A implements Foo { ... } class B extends A { ... }
If someone renames Foo then A and B fails to compile. If you don't want to use an interface, you do it like this:
class A { abstract void foo(); }
class B { void foo() { ... } }
Yes, it's not exactly equivalent but, this is a rather contrived case that never happens in Java because
a) almost everyone uses @Override because IDEs add it automatically b) Java programmers don't refactor by using VI and editing a base class's method names. An IDE like IntelliJ IDE does all the work automatically. c) if you really want to ensure that a class implements a certain interface, you use a Java interface to enforce it.
This swift feature is interesting, but it's not really anything to sell the language.
I don't think Swift is trying to sell itself based on the 'override' modifier, overflow-checked arithmetic, Unicode variable names, or any of the other minor features which people keep on talking about. It has a far more capable type system than Objective-C ever had. Its pattern matching is far more than "C's switch statement, but without automatic fall-through". Except for backwards-compatibility, it de-emphasizes or eschews the many at-runtime dynamic features that Objective-C had (e.g. creating and modifying classes and methods dynamically). It has tuples. It's a huge departure from Objective-C, not just incremental improvements packaged into a new language (not that it invented these new features, of course), so it's doing more than just addressing 'minor qualms'.
[1] D. F. Bacon, P. Cheng, and V. T. Rajan, “A Unified Theory of Garbage Collection,” presented at the Proceedings of the 19th Conference on Object-Oriented Programming, Systems, Languages & Applications (OOPSLA), 2004.
Apple docs:
"Garbage collection is deprecated in OS X Mountain Lion v10.8, and will be removed in a future version of OS X. Automatic Reference Counting is the recommended replacement technology."[1]
[1]https://developer.apple.com/library/ios/releasenotes/objecti...
[2]http://lists.apple.com/archives/objc-language/2011/Jun/msg00...
If we don't use the more common understanding of gc, Apple's documentation doesn't make sense. If we do a substitution of Apple's verbage using ARC==GC, we get nonsense such as:
"Garbage collection (which includes ARC) is deprecated in OS X Mountain Lion v10.8, and will be removed in a future version of OS X. Automatic Reference Counting (which is also part of garbage collection) is the recommended replacement technology."
With the insistence on ARC==GC, we'd have to parse that sentence as garbage collection is being removed and replaced with garbage collection.
For example, what I learned decades ago doesn't include that 2004 paper that convincingly shows reference counting to be one end of a scale that has pure GC at the other end.
Yet, that paper made me realize that reference counting is, in some sense, garbage collection.
On the other hand, I see no big problem in having an ambiguous term. That happen all over the world, also in science. Chemists have 'alcohol' (ethanol) vs 'an alcohol' (a family of compounds that includes ethanol), mathematicians have words such as 'algebra', biologists have roses as a family of plants and as a subset thereof, etc.
Your bit about compile-time code analysis to automatically insert the cleanup code when data is no longer reachable is actually pretty similar to what Rust does today with owned pointers. The downside is that this doesn't work with "normal" code -- you need certain annotations for the compiler to be able to perform this task correctly. In Rust this is done via region pointers (lifetime parameters) and borrow checking.
What the automatic part of ARC does is, at compile time, analyse the code and automatically add the retain and release messages. If it determines the reference will outlive the stack frame, it adds a retain message. if it determines the reference can no longer be dereferenced (maybe because another object reference is assigned to that variable) it adds a release message.
The runtime characteristics are the same as ARC, it just means the programmer no longer needs to work out where to add the retain and release messages (though they still need to think about reference cycles).
Thanks for making this post, I have been meaning to say something similar for a while now. And, re: one of your other posts in this thread, the GC handbook is excellent. One of my favorite textbooks.
What most people on this site call "garbage collection" would be more accurately called "tracing garbage collection."
The proper distinction would be between local reference counting and GC at the time of release, and global heap traversal from roots.
I hate how they didn't make a keyword out of it, even if it meant breaking code.