5 ms·

What he's advocating sounds a lot like how things work in the iOS world, in my experience.

adolph 15y ago
A GC system with explicitly visible reference counts (and immediate freeing) with language support to make it easier to get the refcounts right (things like automatically incrementing the refcounts when passing the object off to others) wouldn't necessarily be painful to use, and would clearly offer all the advantages of just doing it all by hand. I was wondering how that was different from Cocoa on Objective-C. See: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html%23//apple_ref/doc/uid/TP40004447-SW1 http://developer.apple.com/library/mac/#documentation/Cocoa/...
- pdhborges 15y ago
  The runtime system might not free the memory immediately.
  - pohl 15y ago
    Could you expand on this thought? I assumed that free() was invoked in the dealloc method, which was explicitly called if the release method reached a zero ref count.
    - sil3ntmac 15y ago
      That's correct, unless the object is autoreleased, in which case the system will get around to deallocating it after the current run loop iterates (provided you're using the default autorelease pool).
      - DougBTX 15y ago
        Worth noting that an autoreleased object which you haven't retained will have a ref count of 1, so they are not an exception to the "freed when the ref count is zero" idea.
        pdhborges 15y ago
        Yes, but if the object fall into the default autorelease pool you have no way to control when the memory is going to be released (at least without risking a segfault).
      - pohl 15y ago
        Thank you, that makes sense. So, if I understand this correctly: if one wanted to take advantage of an opportunity to do some cache-friendly reallocation, then avoiding autorelease pools would be necessary.
        microtherion 15y ago
        That's rarely a realistic option if you use any Cocoa library code. autorelease is a pretty fundamental aspect of the Cocoa design.
        pohl 15y ago
        Wouldn't it be more accurate to say that it's not a realistic option for objects that come from or depend on Cocoa library code? Or would the mere act of using cocoa in one part of my application somehow prevent me from exploiting such an opportunity in another part of my application? My instinct says that, for example, a plain C library that used such techniques would not cease to function just by being linked into a cocoa application.
        glhaynes 15y ago
        Your instinct is correct.
        microtherion 15y ago
        Yes, you're right: If you create objects yourself and don't pass them through certain Cocoa library code, they will not be autoreleased. What I meant, however, is that most nontrivial Cocoa apps are likely to end up with a checkerboard allocation pattern, where the client allocated, controlled-lifetime objects are interspersed with Cocoa library allocated autoreleased objects with somewhat longer lifetimes, which may interfere to some extent with any strategy relying on controlling your object lifetime. Still, people can and do avoid autoreleasing objects if their lifetimes are well known in advance.
bcl 15y ago
In ObjC the retain/release memory management system uses reference counters. When the count hits zero the object is deallocated so that does sound like what Linus is talking about. Objective C also has the 'new' garbage collection system and there is autorelease which uses a memory pool and releases at some later point.
- lobster_johnson 15y ago
  Objective-C also has the autorelease pool, which allows for a bit more flexibility in that you don't need to pay as much attention to the refcount. You can also optimize allocations using zones, which are like mini-heaps that collect a bunch of objects and allow you to release all of them with a single deallocation -- very handy if you have a ton of small objects (like a DAG) where you know for a fact that when the root is deallocated, all the nodes should be freed as well.
BenoitEssiambre 15y ago
And thus the insanely smooth user experience on iOS. As an Android developer, this is _the one thing_ I feel makes it difficult to have a polished user experience on Android compared to iOS. If you think long and hard about each place you call 'new' in java Android apps, it is possible to get a smooth interface. However, the language doesn't encourage it by default like on iOS and you have to put time into it you usually don't have. For users, milliseconds of jitters and blockiness everywhere is a huge turn off. It feels like the device is struggling to handle simple tasks and it destroys the belief in the UI metaphor of physical objects that have inertia and flow, stretch and bounce when you touch and flick them. IMO, because it makes such a huge difference to users, UI programming should always happen in a high performance language and environment. One way to attain this performance is to eschew garbage collection. This is also a problem in web browsers where the UI is often written in javascript. At the very least those who make programing environments, languages or GCs used for building user interfaces should optimize how their environments promote good use of local hardware cache and acceleration. There is a reason why UI rendering often relies on video hardware that is not totally unlike a desktop high performance computer.
- kenjackson 15y ago
  And thus the insanely smooth user experience on iOS. As an Android developer, this is _the one thing_ I feel makes it difficult to have a polished user experience on Android compared to iOS. Yet for WP7 its also silky smooth. The main issue on WP7 for user apps isn't GC at all, but rather the network (creating long lists of images that you're getting from a web service). Once people learned some techniques for dealing with that on the device the experience for 3rd party apps was just as silky as iOS apps -- yet a full generational GC. The GC is an excuse (unless its not well written), not the reason.
- cpeterso 15y ago
  And that Android's GUI did not use GPU hardware acceleration until Honeycomb. The iOS GUI uses hardware acceleration extensively (which is admittedly probably easier when you control the iOS devices' hardware design). https://code.google.com/p/android/issues/detail?id=6914 https://code.google.com/p/android/issues/detail?id=6914

A GC system with explicitly visible reference counts (and immediate freeing) with language support to make it easier to get the refcounts right (things like automatically incrementing the refcounts when passing the object off to others) wouldn't necessarily be painful to use, and would clearly offer all the advantages of just doing it all by hand. I was wondering how that was different from Cocoa on Objective-C. See: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmPractical.html%23//apple_ref/doc/uid/TP40004447-SW1 http://developer.apple.com/library/mac/#documentation/Cocoa/...

pdhborges 15y ago
The runtime system might not free the memory immediately.
- pohl 15y ago
  Could you expand on this thought? I assumed that free() was invoked in the dealloc method, which was explicitly called if the release method reached a zero ref count.
  - sil3ntmac 15y ago
    That's correct, unless the object is autoreleased, in which case the system will get around to deallocating it after the current run loop iterates (provided you're using the default autorelease pool).
    - DougBTX 15y ago
      Worth noting that an autoreleased object which you haven't retained will have a ref count of 1, so they are not an exception to the "freed when the ref count is zero" idea.
      - pdhborges 15y ago
        Yes, but if the object fall into the default autorelease pool you have no way to control when the memory is going to be released (at least without risking a segfault).
    - pohl 15y ago
      Thank you, that makes sense. So, if I understand this correctly: if one wanted to take advantage of an opportunity to do some cache-friendly reallocation, then avoiding autorelease pools would be necessary.
      - microtherion 15y ago
        That's rarely a realistic option if you use any Cocoa library code. autorelease is a pretty fundamental aspect of the Cocoa design.
        pohl 15y ago
        Wouldn't it be more accurate to say that it's not a realistic option for objects that come from or depend on Cocoa library code? Or would the mere act of using cocoa in one part of my application somehow prevent me from exploiting such an opportunity in another part of my application? My instinct says that, for example, a plain C library that used such techniques would not cease to function just by being linked into a cocoa application.
        glhaynes 15y ago
        Your instinct is correct.
        microtherion 15y ago
        Yes, you're right: If you create objects yourself and don't pass them through certain Cocoa library code, they will not be autoreleased. What I meant, however, is that most nontrivial Cocoa apps are likely to end up with a checkerboard allocation pattern, where the client allocated, controlled-lifetime objects are interspersed with Cocoa library allocated autoreleased objects with somewhat longer lifetimes, which may interfere to some extent with any strategy relying on controlling your object lifetime. Still, people can and do avoid autoreleasing objects if their lifetimes are well known in advance.

bcl 15y ago

In ObjC the retain/release memory management system uses reference counters. When the count hits zero the object is deallocated so that does sound like what Linus is talking about. Objective C also has the 'new' garbage collection system and there is autorelease which uses a memory pool and releases at some later point.

lobster_johnson 15y ago
Objective-C also has the autorelease pool, which allows for a bit more flexibility in that you don't need to pay as much attention to the refcount. You can also optimize allocations using zones, which are like mini-heaps that collect a bunch of objects and allow you to release all of them with a single deallocation -- very handy if you have a ton of small objects (like a DAG) where you know for a fact that when the root is deallocated, all the nodes should be freed as well.

BenoitEssiambre 15y ago

And thus the insanely smooth user experience on iOS. As an Android developer, this is _the one thing_ I feel makes it difficult to have a polished user experience on Android compared to iOS. If you think long and hard about each place you call 'new' in java Android apps, it is possible to get a smooth interface. However, the language doesn't encourage it by default like on iOS and you have to put time into it you usually don't have. For users, milliseconds of jitters and blockiness everywhere is a huge turn off. It feels like the device is struggling to handle simple tasks and it destroys the belief in the UI metaphor of physical objects that have inertia and flow, stretch and bounce when you touch and flick them. IMO, because it makes such a huge difference to users, UI programming should always happen in a high performance language and environment. One way to attain this performance is to eschew garbage collection. This is also a problem in web browsers where the UI is often written in javascript. At the very least those who make programing environments, languages or GCs used for building user interfaces should optimize how their environments promote good use of local hardware cache and acceleration. There is a reason why UI rendering often relies on video hardware that is not totally unlike a desktop high performance computer.

kenjackson 15y ago
And thus the insanely smooth user experience on iOS. As an Android developer, this is _the one thing_ I feel makes it difficult to have a polished user experience on Android compared to iOS. Yet for WP7 its also silky smooth. The main issue on WP7 for user apps isn't GC at all, but rather the network (creating long lists of images that you're getting from a web service). Once people learned some techniques for dealing with that on the device the experience for 3rd party apps was just as silky as iOS apps -- yet a full generational GC. The GC is an excuse (unless its not well written), not the reason.
cpeterso 15y ago
And that Android's GUI did not use GPU hardware acceleration until Honeycomb. The iOS GUI uses hardware acceleration extensively (which is admittedly probably easier when you control the iOS devices' hardware design). https://code.google.com/p/android/issues/detail?id=6914 https://code.google.com/p/android/issues/detail?id=6914