4 ms·

Not true. A reference counted program is deterministic, it is known in advance for a given set of inputs exactly when deallocation will occur. Also, its not re

Not true. A reference counted program is deterministic, it is known in advance for a given set of inputs exactly when deallocation will occur. Also, its not really fair to sweep "hard timing constraints" under the rug as a minority use case when these are essential for smooth modern GUIs. Sure, GC is pretty much ideal in terms of absolving developers of resource management responsibilities, but it comes with some significant downsides which can easily effect the final product and should be understated. Rust is a great example of a new language which avoids GC for this reason.

pjmlp 12y ago
You cannot know how much the deallocation impact will be, if a big datastructure is getting its count to 0.
- jahewson 12y ago
  Of course you can know that, because you know the type of every object. If you're deallocating a big data structure, then the impact will be big. Its easy to choose not to deallocate such objects at an inconvinient time by holding references to them. Compare this with GC where the collection can occur at any time after deallocation, e.g. during an animation.
  - danbruc 12y ago
    You can do almost the same with a garbage collector - keep references alive until a convenient point is reached, than kill those last references and manually force a collection. Not that it seems a good idea, but if you need a level of control as described by you, then you are already actively fighting against automatic reference counting and there seems no point to use any kind of automatic resource management in the first place, at least for the relevant objects.
    - jahewson 12y ago
      It's not possible to do that in Java, though it would work in C#. Retaining references really is not "fighting against automatic reference counting", it's the opposite: the reference clearly and unambiguously defines the lifetime of the object, including deallocation. This is by design and ARC can still be used for any shared references to the object. Forcing GC on the other hand, would be fighting against it because you're circumventing its usual operation.
      - Skinney 12y ago
        It wouldn't work reliably in C# either. Both platforms allow you to inform the GC that now would be a good time to collect, but in both systems the GC can ignore your advice. C# has structs which will try to allocate on the stack, but that is potentially a big (or impossible) refactoring on your program (unless you plan ahead).
      - cromwellian 12y ago
        I think technically you could achieve this by having multiple heaps, kind of like custom allocators in other languages. If Java had a placement syntax like new (HeapReference) SomeClass(); => allocate in custom Heap Then you could just turn off GC for that heap, and then blow the whole thing away when it got full. Or, you could have a more fine grained API to allow GC on these custom heaps. Perhaps you could even allow copying objects back to the main heap. You'd have to ban cross heap references or have a smart API that lets users pin an object in the main heap while it is known to be referenced by an object in custom heap. Most of the time in client applications, you only care about GC pauses on the main UI rendering thread, but GC pauses in other threads are less obvious because there's no jank, just that latency may go up for some operations. You could have a kind of best of both worlds with languages that support non-GC allocation for your UI thread, but GC everywhere else.
        pjmlp 12y ago
        You just did a partial description how real time Java works.
  - pjmlp 12y ago
    It is also possible to know, approximately, when a GC collection will take place, this is what GC profilers are for. The thing is that most discussions tend to be reduced to RC vs GC, as if all GCs or RCs where alike, whereas the reality is more complex than that. RC, usually boils down to dumb RC, deferred RC or RC with couting elision via the compiler. Additionally it can have weak references or rely on a cycle collector. Whereas GC, can be simple mark-and-sweep, conservative, incremental, generational, concurrent, parallel, real time, with phantom and weak references, constrainted pause times, coloured.... As for frame drops during animations, I think pauses in a missile control system is not something one wishes for: http://www.militaryaerospace.com/articles/2009/03/thales-chooses-aonix-perc-virtual-machine-software-for-ballistic-missile-radar.html http://www.militaryaerospace.com/articles/2009/03/thales-cho... http://www.spacewar.com/reports/Lockheed_Martin_Selects_Aonix_PERC_Virtual_Machine_For_Aegis_Weapon_System_999.html http://www.spacewar.com/reports/Lockheed_Martin_Selects_Aoni...
    - jahewson 12y ago
      Sure, but then real-time systems are a very special use case with their own languages, tools and techniques. Real time GCs are severely limited and would not be suitable for use in a general purpose context.
  - Skinney 12y ago
    A GC cannot occur at any tie after deallocation. Well, I guess it depends on the collector really, but usually it happens on allocation. If you avoid allocations, you also avoid collections.
danbruc 12y ago
That is a pretty theoretical scenario, at least I usually have no idea in advance what the user input will be. And garbage collectors pausing program execution is not a fundamental problem, there are garbage collectors operating entirely in parallel with normal program execution. Even further, garbage collection itself seem not to be the main source of those pauses, but heap compactification, which you also lose if you use automatic reference counting (or have to do manually).
- jahewson 12y ago
  I didn't say you had to know the inputs in advance. What's known in advance is when deallocation will occur, i.e. its deterministic. You know exactly when deallocation will occur. Heap compaction is another part of GC which results in long non-deterministic pauses. But the real problem is having fragmentation in the first place, this is something which manual allocation strategies can go a long way to mitigate.
  - danbruc 12y ago
    How can you know when a deallocation will occur? Did the user add this product to a single invoice and the product object will get deallocated when closing this invoice form or is there a second invoice still referencing the product? At best you can know when a dealloction might possibly occur, but this is whenever a reference changes or goes away and usually not pretty helpful. For any sufficiently complex real world application you will not in general know when a deallocation occurs and that is one of the reasons you decided to use automatic reference counting in the first place. Some short lived objects within a function are non-issues to begin with and are easily handled manually if you want to, but the interesting bits and pieces are objects with unpredictable life time and usage pattern because they are heavily influenced by inputs.
    - jahewson 12y ago
      When will a deallocation occur? When release is called and the referece count is zero. This is deterministic, unlike GC which will perform the deallocation when it feels like it. I think you've confused determinism with regards to a program and the inputs to that program. Any retain/release program is deterministic because it always behaves in the same manner. Given any possible input I can tell you exactly when and on which lines of code the deallocations will occur. You can't know that with GC, especially when other libraries and threads enter the equation. Which deallocations occur and in which order depend on the input to the program, but we still know in advance all possible lines of code where specific deallocations can occur and we have complete control over that. With GC we wouldn't know that and we couldn't control it. Knowing when deallocations can occur and having control over that is the reason to choose ARC over GC in the first place. Not the other way around. With respect to manual retain/release, ARC doesn't take anything away: I can still retain an extra count of a large object to prevent its untimely release and share that object via ARC at the same time.

pjmlp 12y ago

You cannot know how much the deallocation impact will be, if a big datastructure is getting its count to 0.

jahewson 12y ago
Of course you can know that, because you know the type of every object. If you're deallocating a big data structure, then the impact will be big. Its easy to choose not to deallocate such objects at an inconvinient time by holding references to them. Compare this with GC where the collection can occur at any time after deallocation, e.g. during an animation.
- danbruc 12y ago
  You can do almost the same with a garbage collector - keep references alive until a convenient point is reached, than kill those last references and manually force a collection. Not that it seems a good idea, but if you need a level of control as described by you, then you are already actively fighting against automatic reference counting and there seems no point to use any kind of automatic resource management in the first place, at least for the relevant objects.
  - jahewson 12y ago
    It's not possible to do that in Java, though it would work in C#. Retaining references really is not "fighting against automatic reference counting", it's the opposite: the reference clearly and unambiguously defines the lifetime of the object, including deallocation. This is by design and ARC can still be used for any shared references to the object. Forcing GC on the other hand, would be fighting against it because you're circumventing its usual operation.
    - Skinney 12y ago
      It wouldn't work reliably in C# either. Both platforms allow you to inform the GC that now would be a good time to collect, but in both systems the GC can ignore your advice. C# has structs which will try to allocate on the stack, but that is potentially a big (or impossible) refactoring on your program (unless you plan ahead).
    - cromwellian 12y ago
      I think technically you could achieve this by having multiple heaps, kind of like custom allocators in other languages. If Java had a placement syntax like new (HeapReference) SomeClass(); => allocate in custom Heap Then you could just turn off GC for that heap, and then blow the whole thing away when it got full. Or, you could have a more fine grained API to allow GC on these custom heaps. Perhaps you could even allow copying objects back to the main heap. You'd have to ban cross heap references or have a smart API that lets users pin an object in the main heap while it is known to be referenced by an object in custom heap. Most of the time in client applications, you only care about GC pauses on the main UI rendering thread, but GC pauses in other threads are less obvious because there's no jank, just that latency may go up for some operations. You could have a kind of best of both worlds with languages that support non-GC allocation for your UI thread, but GC everywhere else.
      - pjmlp 12y ago
        You just did a partial description how real time Java works.
- pjmlp 12y ago
  It is also possible to know, approximately, when a GC collection will take place, this is what GC profilers are for. The thing is that most discussions tend to be reduced to RC vs GC, as if all GCs or RCs where alike, whereas the reality is more complex than that. RC, usually boils down to dumb RC, deferred RC or RC with couting elision via the compiler. Additionally it can have weak references or rely on a cycle collector. Whereas GC, can be simple mark-and-sweep, conservative, incremental, generational, concurrent, parallel, real time, with phantom and weak references, constrainted pause times, coloured.... As for frame drops during animations, I think pauses in a missile control system is not something one wishes for: http://www.militaryaerospace.com/articles/2009/03/thales-chooses-aonix-perc-virtual-machine-software-for-ballistic-missile-radar.html http://www.militaryaerospace.com/articles/2009/03/thales-cho... http://www.spacewar.com/reports/Lockheed_Martin_Selects_Aonix_PERC_Virtual_Machine_For_Aegis_Weapon_System_999.html http://www.spacewar.com/reports/Lockheed_Martin_Selects_Aoni...
  - jahewson 12y ago
    Sure, but then real-time systems are a very special use case with their own languages, tools and techniques. Real time GCs are severely limited and would not be suitable for use in a general purpose context.
- Skinney 12y ago
  A GC cannot occur at any tie after deallocation. Well, I guess it depends on the collector really, but usually it happens on allocation. If you avoid allocations, you also avoid collections.

danbruc 12y ago

That is a pretty theoretical scenario, at least I usually have no idea in advance what the user input will be. And garbage collectors pausing program execution is not a fundamental problem, there are garbage collectors operating entirely in parallel with normal program execution. Even further, garbage collection itself seem not to be the main source of those pauses, but heap compactification, which you also lose if you use automatic reference counting (or have to do manually).

jahewson 12y ago
I didn't say you had to know the inputs in advance. What's known in advance is when deallocation will occur, i.e. its deterministic. You know exactly when deallocation will occur. Heap compaction is another part of GC which results in long non-deterministic pauses. But the real problem is having fragmentation in the first place, this is something which manual allocation strategies can go a long way to mitigate.
- danbruc 12y ago
  How can you know when a deallocation will occur? Did the user add this product to a single invoice and the product object will get deallocated when closing this invoice form or is there a second invoice still referencing the product? At best you can know when a dealloction might possibly occur, but this is whenever a reference changes or goes away and usually not pretty helpful. For any sufficiently complex real world application you will not in general know when a deallocation occurs and that is one of the reasons you decided to use automatic reference counting in the first place. Some short lived objects within a function are non-issues to begin with and are easily handled manually if you want to, but the interesting bits and pieces are objects with unpredictable life time and usage pattern because they are heavily influenced by inputs.
  - jahewson 12y ago
    When will a deallocation occur? When release is called and the referece count is zero. This is deterministic, unlike GC which will perform the deallocation when it feels like it. I think you've confused determinism with regards to a program and the inputs to that program. Any retain/release program is deterministic because it always behaves in the same manner. Given any possible input I can tell you exactly when and on which lines of code the deallocations will occur. You can't know that with GC, especially when other libraries and threads enter the equation. Which deallocations occur and in which order depend on the input to the program, but we still know in advance all possible lines of code where specific deallocations can occur and we have complete control over that. With GC we wouldn't know that and we couldn't control it. Knowing when deallocations can occur and having control over that is the reason to choose ARC over GC in the first place. Not the other way around. With respect to manual retain/release, ARC doesn't take anything away: I can still retain an extra count of a large object to prevent its untimely release and share that object via ARC at the same time.