On Sun, 2007-12-16 at 22:07 -0500, Sandro Magi wrote:
> The only real performance bottlenecks for garbage collected languages
> are tight heaps as found in small devices, and large heaps with virtual
> memory where tracing causes thrashing [1]. Unfortunately, server-side
> systems can fall into the latter category.
This is not entirely correct. Or rather, it *should* be correct, but it
is often incorrect in practice.
First, there is the problem of garbage retention. This results from dead
pointer slots on the stack that have not been nullified. Solutions have
long been known, but are not widely implemented.
Second, there is the pragmatic problem that most of the popular
languages of this sort have to interface with C. In many cases (though
perhaps not in Java) this forces them to conservative collectors, which
are horrible.
Finally, there is the problem that when something *does* go wrong with
GC, there are no tools to help you find the culprit (and it isn't clear
how one would design such tools).
Note, however, that all of these costs are associated with GC rather
than safety per se. The only substantive execution-time overheads of
these languages have to do with things like "true" integers, and the
fact that many implementations therefore cannot exploit simplified
register arithmetic. A lot of that can be made to go away by a
sufficiently aggressive compiler, but I do not know if such compiler
technology is widely deployed. I doubt it.
Hotspot is largely irrelevant for server applications. Technologies like
hotspot have a higher startup cost to reach a more efficient stable
state. The problem is that web transactions are short, so you never
really get the payoff from this type of technology.
shap