On 5/1/06, Archie Cobbs <[EMAIL PROTECTED]> wrote:
Weldon Washburn wrote:
> 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.
JVM specification, section 4.1:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#74353
If the ACC_INTERFACE flag of this class file is set, its ACC_ABSTRACT
flag must also be set (ยง2.13.1) and its ACC_PUBLIC flag may be set.
Such a class file may not have any of the other flags in Table 4.1 set.
It's interesting to hear that Sun (I assume?) doesn't follow this.
Archie,
Are you able to confirm the behavior I am seeing on your system? I
ask because I would hate to find out the problem is caused by some
glitch in my environment. You should be able to test for the problem
with specJVM98 _209_db. Because of spec licensing rules, I may not be
able to give you my hacked up source to try.
> 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.
JCHEVM does agressive linking. This behavior is inherited from JCVM
which was optimized for pre-compiled objects. Agressive linking is
within the JVM spec, which allows flexibility in this area. The problem
you see is one downside of the approach.
hmmm.... is there any facility to turn off JCHEVM's agressive linking?
That is, let the linking happen only at first use of the class. If
not, the choices are to:
a)
implement AWT and any other missing libs (this may be lots of work)
b)
comment out unused but offending classes that are in specJVM98 (ugly!)
c)
use some other benchmarks to demo Harmony LUNI on gnuclasspathadapter
(and have to respond to questions why specJVM98 does not work)
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
