GC has little relation to optimizations advanced processors
perform.
This may be true in theory; however, from what I've heard and seen,
people writing XSLT processors in languages without automatic garbage
collection have had to spend an enormous amount of effort doing the
memory management, effort which might otherwise have been spent on
rewrite optimizations.
A processor written in C will be faster than a Java processor in the
end, but only after you've written about 5 times as many lines of code;
and even then, it will probably have memory leaks.
That can be an issue, but not as severe as 5 times difference in effort.
First, while writing manual memory management for C data structures in
the traditional way is a nightmare, implementing compressing mark-and-sweep
for a particular class of data structures, such as nodes, is easy.
Besides, there is a very efficient implementation of GC for C, and it is
proved to work for many applications. I mean Boehm's collector,
http://www.hpl.hp.com/personal/Hans_Boehm/gc/. If use of GC makes writing XSLT
processors so much faster, their authors should consider using it. By the way,
Hans Boehm, the author of the implementation and a proponent of GC, estimates
efforts devoted to storage managements as 30%-40%.
David Tolpin
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list