Hi Matz,

This is very interesting.  Therefore, just from the GC overhead point of
view, if the JVM uses simple mark and sweep, I will guess then Ruby
performance will be comparable to Java (using comparable GC parameters of 
course)... (and therefore network simulators may not perform as well in
Java as in C++, especially for large-scale networks...)

Which brings us to the second topic: the object model.  In Ruby, in the
spirit of Smalltalk, everything is an object.  In Java, certain data types
(such as int, float, and double) are "native" while the rest are
objects.  In Ruby, I guess for optimization purpose, you have put the
'int' as an immediate object, at the cost of 1 bit.  Therefore, in the
future, when 64-bit pointer is very common, will you also put the 'double'
as an immediate object, and therefore probably approaching the Java model?

(Actually, at least in theory, we currently can also put 'float' as an
immediate object, can't we?  But probably it is not as simple as providing
BigFloat and FixFloat, as the mantissa also differs, not just the
exponent.  Has there been any study/experiment/survey on how much having
both "immediate object" and "pointer object" saves as compared to the
simpler model of "everything is pointer object"?  I guess having
everything as pointer object will make the C API's simpler.)

Regards,

Bill
=============================================================================
Yukihiro Matsumoto <matz / ruby-lang.org> wrote:
> |I think Java also has a garbage collector (also mark and sweep type, I
> |think), and Java has been used in large-scale enterprise
> |applications.  Can we at least try to understand how Java deal with the
> |scalability issue of mark-and-sweep GC?

> Depends on each VM implementation.  JVM specification does not require
> GC in fact.  Some uses simple mark and sweep, some uses more
> sophisticated train algorithm (a variation of generationa GC).

> 							matz.