Taste
Posted Sep 6, 2007 20:39 UTC (Thu) by
mikov (subscriber, #33179)
In reply to:
Taste by lysse
Parent article:
LinuxConf.eu: Documentation and user-space API design
In practice, with the current GC implementations and languages, GC is both slow and noticeable. There is no point in arguing this at all, because I experience it every day - in the Java applications I develop, as well as the ones I use.
You could say that I should use another vendor's implementation (e.g. - http://domino.research.ibm.com/comm/research_projects.nsf... - which AFAIK isn't free), or use this or that magical runtime option (naturally after doing heavy profiling), or move to a quad core CPU, but that doesn't change the _default_ situation.
Plus, technically speaking, GC is extremely complex and complexity isn't free.
You cannot have fast concurrent GC without affecting and significantly complicating the generated code - you need to track asynchronous changes, synchronize threads, etc - all very complicated and error prone operations that have a definite cost. It is no accident that there are no accurate concurrent open source collectors. AFAIK the Mono developers are working on something - http://www.mono-project.com/Compacting_GC - but it is not ready yet.
(
Log in to post comments)