Re: mauve results posted nightly

[Stuart Ballard]

Mark Wielaard wrote:
> 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 :)

Sounds like an argument in favor of, or against, native java.util.zip ;) 
Or does this performance difference apply regardless of compression?

> 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

>  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

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.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;

>  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

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...

Stuart.

--
Stuart Ballard, Programmer
NetReach - Internet Solutions
(215) 283-2300, ext. 126
http://www.netreach.com/