Mark Wielaard wrote:
Sounds like an argument in favor of, or against, native java.util.zip ;) Or does this performance difference apply regardless of compression?Hi,It is also very fast compared with Kissme. Kissme took 1 minute and 50 seconds for only the java.util package and subpackages. gij took just 25 seconds for ALL java.* and subpackages! This is with the gij interpreter, I really want to see this when I can compile from source with -O2 :)
The uncompressed results of the kissme and gij version are completely the same. But the compressed file that kissme produces seems to contain a lot of trailing garbage (gunzip complains about it but still manages to uncompress it). I haven't looked into this yet.
Presumably a java.util.zip bug.
(where INTERPRETER == gij || Sun j2sdk 1.4 java) produced almost identical files but there were a few small differences. I also haven't looked into this yet. (diff attached) But this is probably one of the runtimes picking up a constant from its own runtime library and not from the GNU Classpath glibj.zip file.
See below for my comments...
java.lang,Double!#MAX_VALUE Pcsf D:1.7976931348623157E308 -java.lang,Double!#MIN_VALUE Pcsf D:5.0E-324 +java.lang,Double!#MIN_VALUE Pcsf D:4.9E-324 java.lang,Double!#NEGATIVE_INFINITY Pcsf D:-Infinity
These look like they could well be floating-point output bugs. Sun has a very complex and highly specified algorithm for exactly what significant figures should be printed for any given floating point number: it's entirely possible that Classpath doesn't implement that algorithm perfectly. (I think I commented in the source code that "this also tests toString() on floating point numbers" or something to that effect).java.lang,Float!#MAX_VALUE Pcsf F:3.4028235E38 -java.lang,Float!#MIN_VALUE Pcsf F:1.4012985E-45 +java.lang,Float!#MIN_VALUE Pcsf F:1.4E-45 java.lang,Float!#NEGATIVE_INFINITY Pcsf F:-Infinity
java.security,Signer!getPrivateKey() Pcin Ljava/security/PrivateKey; -java.security,Signer!getPublicKey() Pcin Ljava/security/PublicKey; +java.security,Signer!getPublicKey() Pcin Ljava/security/PublicKey;*java.security.KeyManagementException java.security,Signer!getScope() Pcif Ljava/security/IdentityScope;
These are more interesting as they boil down to the question of "is KeyManagementException a subclass of RuntimeException?". If it is, it should be excluded from the throws clause; if not, it should be included. I'm curious as to why jode is giving different results depending on which JVM is running it...java.security,Signer!toString() Pcin Ljava/lang/String;*java.security.KeyManagementException -java.security,Signer!toString(Z) Pcin Ljava/lang/String; +java.security,Signer!toString(Z) Pcin Ljava/lang/String;*java.security.KeyManagementException java.security,Signer!wait() Pcif V*java.lang.InterruptedException
Stuart.
--
Stuart Ballard, Programmer
NetReach - Internet Solutions
(215) 283-2300, ext. 126
http://www.netreach.com/
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
