harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib] gnuclasspathadapter -- current status on getting specJVM98 to run
Date Mon, 01 May 2006 02:42:11 GMT
excellent :)

Weldon Washburn wrote:
> A new zip file has been uploaded to JIRA Harmony-318.
> 
> Current status:
> 
> The _209_db benchmark from specjvm98 initializes but fails to
> complete.  The current roadblock is opening the database files.  There
> may be a problem with absolute and relative path names.  
> System.out.println() now works.  This is finally allowing printf-style
> debug statements to be sprinkled in Java code.  This is a big
> improvement over the previous debug facility (looking at raw Java heap
> memory using gdb.)
> 
> There was an unexpected and surprising parsing problem when running
> _209_db on JCHEVM.  The procedure called, _jc_parse_classfile(), does
> some basic verification of a class file.  In specific, it verifies
> that a class with the ACC_INTERFACE attribute set also has the
> ACC_ABSTRACT bit set.  It turns out that _209_db has an interface
> without the abstract bit set.  _209_db will run without warning or
> error on a product JVM but throws a "ClassFormatError" on JCHEVM.  The
> temporary patch is to comment out JCHEVM code that throws the
> ClassFormatError.  This problem needs further investigation.
> 
> Another problem is that JCHEVM seems to throw a fatal exception during
> load time if the code being loaded refers to a class that is nowhere
> to be found.  I think the JVM Spec says this exception should be
> delayed until execution time.  The specific problem is that _209_db
> code refers to AWT classes.  Even though _209_db is run with the
> console configuration, when the classes load they cause JCHEVM to
> attempt to load AWT classes that can't be found.   The workaround is
> really ugly -- comment out the AWT code in the spec benchmarks.
> 
> Java.lang.System.getEncoding() – the code is not correct but does not
> appear to be a roadblock currently.  The encoding issue kept coming up
> during debug for some reason.  This needs help from someone who really
> understands JVM language encoding.
> 
> Java.lang.String has some very sneaky incomplete methods in it!  Hours
> were spent looking at the interpreter's call stack to discover that
> the method String.print(String) was setting the string to be printed
> to null.  Since this is in the direct path of a "System.out.println()"
> it was impossible to put debug print statements in the source code to
> speed up debugging.  Lots of time spent digging throught
> NullPointerExceptions.
> 
> Basic Java.io.File functionality now works.  Virtually all the
> modifications were to the native methods that support
> java.io.File.java.  While the goal is full compliance with Harmony
> Classlib porting layer, temporary shortcuts were taken.  In other
> words, the native methods were connected directly to POSIX I/O APIs
> instead of Harmony porting layer.
> 
> Let me know if you have questions.
> 
> -- 
> Weldon Washburn
> Intel Middleware Products Division
> 
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message