harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [classlib] gnuclasspathadapter -- current status on getting specJVM98 to run
Date Mon, 01 May 2006 16:42:26 GMT
On 5/1/06, Archie Cobbs <archie@dellroad.org> 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: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


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