harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject [classlib] gnuclasspathadapter -- current status on getting specJVM98 to run
Date Mon, 01 May 2006 01:38:02 GMT
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


Mime
View raw message