Recent Features
| |||||||||||||
TasteTastePosted Sep 6, 2007 15:42 UTC (Thu) by lysse (guest, #3190)In reply to: Taste by IkeTo Parent article: LinuxConf.eu: Documentation and user-space API design
> You focus too much on the Java side
...which is presumably why I didn't reference two other languages that allow precisely what you're complaining about garbage collected languages not allowing - oh, wait...
> and missed the point intended: on the C++ side, no object "creation" or "destruction" cost is needed for passing arguments by reference.
*sigh* What I said went completely over your head, didn't it...?
Again, that's EXACTLY the point I caught and responded to. Allocating objects on the stack and passing parameters by reference are, contrary to your apparent belief, neither innovations in C++, nor rendered impossible in a garbage collected language; again I cite Oberon, which is just fine with both and yet fully GC'd.
And the issue of whether every first-class, dynamically-allocated object a language deals with must be allocated on the heap is a different one again; lots of optimisations, of varying degrees of complexity, are known that reduce the heap burden substantially. (Indeed, the MLkit compiler statically tracks object lifetimes and allocates up to eight different stacks in heapspace, giving compiled ML programs the speed of stack allocation with the correctness of garbage collection.) But even when all objects must be heap-allocated, it's not necessarily the end of the world in performance terms; Appel (1987) shows that garbage collection can still end up faster than stack-based allocation.
(Log in to post comments)
Taste Posted Sep 6, 2007 16:00 UTC (Thu) by IkeTo (subscriber, #2122) [Link] > Allocating objects on the stack and passing parameters by reference are,> contrary to your apparent belief, neither innovations in C++, nor rendered > impossible in a garbage collected language; again I cite Oberon, which is > just fine with both and yet fully GC'd.
I never say they are never "rendered impossible" (Even C++ does that!), and the "apparent belief" seems very speculative (e.g., Even assembly does stack based allocation!). Let me remind the beginning of my original post.
> "I think one problem of *many* GC systems is that..."
What I mean is that many "short-comings" that others talk about GC are not intrinsic to the availability of GC, but instead they are due to particular languages which have made certain choices, like which of the allocations they choose to tax the GC system. Again, most people should not care at all.
> Appel (1987) shows that garbage collection can still end up faster than
I'm interested in this work. Is it available on-line, or if not, can you give the name of the journal/conference where it appear in?
Taste Posted Sep 6, 2007 16:16 UTC (Thu) by lysse (guest, #3190) [Link] > What I mean is that many "short-comings" that others talk about GC are not intrinsic to the availability of GC, but instead they are due to particular languages which have made certain choices, like which of the allocations they choose to tax the GC system. Again, most people should not care at all.
In that case, then I thoroughly misunderstood you - I thought you were making exactly this mistake yourself. Sorry.
> I'm interested in this work. Is it available on-line, or if not, can you give the name of the journal/conference where it appear in?
It's available online: http://citeseer.ist.psu.edu/appel87garbage.html
Taste Posted Sep 6, 2007 17:03 UTC (Thu) by IkeTo (subscriber, #2122) [Link] > It's available online: http://citeseer.ist.psu.edu/appel87garbage.html
Thanks. Just read it briefly. I would not agree that GC is faster than stack allocation because of that, though. I echo Stroustrup's joke that if you have that much memory you are supposed to use them to prevent any process from getting into the swap. =)
Taste Posted Sep 7, 2007 23:48 UTC (Fri) by lysse (guest, #3190) [Link] Fair enough, but his opinion was peer-reviewed. :)
Taste Posted Sep 8, 2007 6:41 UTC (Sat) by IkeTo (subscriber, #2122) [Link] > Fair enough, but his opinion was peer-reviewed. :)
Peer review process seldom block correct but practically irrelevant work. :)
|
|||||||||||||