From: William Djaja Tjokroaminata Date: 2002-09-06T01:08:04+09:00 Subject: Re: Best GC for Ruby? 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 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.