A re-announce on GC's defects

GC is really garbage itself



Reason 1:



There is delay between the wanted destruction and the actual destruction.



Negative effects by the destruction delay:



1) Efficiency issue



It's bad for CPU/Resource intensive but memory cheap objects.



CPU intensive objects refer to objects who own internal threads.

Resource intensive objects refer to objects who own unmanaged resources like
file handle, network connections, etc.



Don't tell me these objects are rare. Everything is possible to happen and a
general purpose language should not find any excuse not to apply to some
situations.



2) Logic issue



The need for weak reference makes the destruction delay logically incorrect.



Weak references (or you can call them handles) refer to references who do
not require the referenced targets to keep alive, while strong references
do.



When all strong references to a target go out of their lifetime, the target
also comes to the end of its lifetime. Right at this point, weak references
to this target become invalid. However, the destruction delay caused by the
GC violates this logic. Weak references will continue to think the target
alive until the GC really collects the target object.



Don't tell me the IDispose pattern is for that. There may be more than one
strong references and you don't know when and where to call Dispose.



Don't tell me WeakReference (C#) is for that. If you don't have Dispose
called properly, WeakReference still gives a wrong logic.



Don't tell me this can be solved by adding method like IsDestroyed to the
target. It holds a candle to the sun and it only adds to the complexity of
logics.



An example:

Suppose we're doing a 3D game. A radar is monitoring a target. Obviously,
the radar should hold a weak reference to the target. When the target is
killed, logical confusion is immediately brought to the radar watcher (the
gamer). Is the target destroyed or not? You can not tell him, hey, it's
killed but still shown on the radar because you've got to wait for the GC to
make it.





Reason 2:



Poor scalability



This is a Theory issue.



GC is global, which means it scales as the application's memory use scales.
Theoretically, this indicates a bad scalability.



Don't tell me an application should not use too many concurrent objects.
Again, everything is possible. Restrictions only prove the defects of the
language.





Fairly speaking, GC itself is not garbage. However, when java and C#
integrate it and prevent the user from manually managing memory, it becomes
garbage. Note GC in java and C# is not really an addictive as someone would
argue since there is no way to do real memory management like delete obj in
C++.



Better memory management in my mind is reference counting + smart pointer,
which makes things automatic and correct. You have deterministic
destructions while no need to manually call Dispose. You need not to
manually change the reference count as smart pointers help you achieve it.
The only problem with this approach is cyclic reference. However, even if
not theoretically proven, the problem generally can be solved by replacing
some strong references with weak references.



I believe the restriction by GC is one of the main reasons why in some field
(the gaming industry, for example), java or C# is rarely used in serious
products who face real computing challenges.





Solution



1) The ideal solution is to convince the language providers to give us back
the ability of managing memory by our own. GC can still be there, and it
becomes a real addictive in that situation.



2) Transfer the burden to the user. We can ask the user to always take
special cautions (for example, always use "using" in C# to have Dispose
correctly called even exception occurs). Things can work around if the user
do them right. However, that's at risk in nature and not a robust solution.


.

Relevant Pages

  • Re: A re-announce on GCs defects
    ... There is delay between the wanted destruction and the actual destruction. ... It's bad for CPU/Resource intensive but memory cheap objects. ... Weak references refer to references who do ... When all strong references to a target go out of their lifetime, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: sms overriding my specification of target volume
    ... I only use volume references for target datasets. ... and SMP/E land in SMS managed pools. ... sms overriding my specification of target volume ...
    (bit.listserv.ibm-main)
  • Re: Bypassing __getattribute__ for attribute access
    ... def c: pass ... So when itself looked up, it returns a method object, which when called passes the 'target' object as first arg. ... to this class so that future references to x.set_xand X.set_x will ...
    (comp.lang.python)
  • Re: Can someone explain this weakref behavior?
    ... >> is more robust than simply incrementing and decrementing class variables ... >> immediately deleting the weak reference as soon as all references to the ... >> behavior of weak references? ... refcount of zero. ...
    (comp.lang.python)
  • Re: nss_ldap broken
    ... I had no idea that libpthread would be loaded then unloaded. ... I'm unsure how nss_ldap was built to depend on libpthread (or ... weak references (not definitions, like you see in our libc ... By making the pthread_* references weak, you don't need to be linked ...
    (freebsd-current)