| |||||||||||||
Java is new TkJava is new TkPosted Aug 21, 2011 6:58 UTC (Sun) by tzafrir (subscriber, #11501)In reply to: Java is new Tk by cmccabe Parent article: HP dropping webOS devices
Most of the other "languages" (or rather: their implementations) that you mention as using garbage collection use a reference counting one, IIRC:
Javascript, Ruby (most implementations - except, maybe, JRuby and IronRuby), Python (except JPython?), etc. C++ likewise has its own reference counting partial garbage collection facility.
With reference counting there's no inherent need for a single pass (or an elaborate way to work around the need for one).
(Log in to post comments)
Refcounting is fine... Posted Aug 21, 2011 8:39 UTC (Sun) by khim (subscriber, #9252) [Link] With refcounting you still must think about objects lifetime. Thus you still will create sane designs because you must make sure you'll not create loops. But full GC encourages "don't know and don't care when this object will be removed" designs - and these can only be fixed with full rewrite.
Refcounting is fine... Posted Aug 31, 2011 14:25 UTC (Wed) by nix (subscriber, #2304) [Link]
Er, recursive reference loops are common in all sorts of designs. In pure refcounted ones, you have to use crocks like having a single object registry and having everything else have references to it, even if that is otherwise unnatural. A good few refcounted implementations (including Python and IIRC Ruby too) collect cyclic garbage just fine, by having a conventional GC as well (in Python's case, a generational GC with a variety of optimizations to take into account that most garbage is already collected by the refcounter, so most of what it will see is uncollectable).
Java is new Tk Posted Aug 27, 2011 18:30 UTC (Sat) by BenHutchings (subscriber, #37955) [Link]
Reference counting can't deal with cycles. Some languages just bail on this (e.g. Perl) but most use a real GC. Even though CPython does reference counting it also has a real GC to break cycles. In a web browser, Javascript code is not trusted, so any implementation must implement real GC.
Reference counting can also result in long pauses due to cascading destruction. In fact, it can be worse than incremental GC in this respect.
Java is new Tk Posted Aug 27, 2011 23:47 UTC (Sat) by andresfreund (subscriber, #69562) [Link]
Its not like its impossible to delay destruction in a refcounted scheme. Doing so should be rather simple.
I guess the point is that predictable deletion has nice properties to implement things in an RAIIish fashion which probably outweighs the problems of expensive cascading deletion.
Java is new Tk Posted Aug 28, 2011 23:03 UTC (Sun) by foom (subscriber, #14868) [Link]
The problem is that it's not actually predictable. It only *seems* predictable. But you could create a reference cycle pointing to your object, and all of a sudden, whoops, doesn't get destructed when you thought it was going to anymore.
There's a reason that Python introduced the "with" statement: to allow for easily-written *actually* predictable resource closing.
|
|||||||||||||