Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 1779 invoked from network); 1 May 2006 16:42:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 1 May 2006 16:42:52 -0000 Received: (qmail 96542 invoked by uid 500); 1 May 2006 16:42:51 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 95855 invoked by uid 500); 1 May 2006 16:42:48 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 95844 invoked by uid 99); 1 May 2006 16:42:48 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 May 2006 09:42:48 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of weldonwjw@gmail.com designates 64.233.166.178 as permitted sender) Received: from [64.233.166.178] (HELO pproxy.gmail.com) (64.233.166.178) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 01 May 2006 09:42:47 -0700 Received: by pproxy.gmail.com with SMTP id c31so2020281pyd for ; Mon, 01 May 2006 09:42:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RpHGwdgop4Pg4po6fI5wdMJUP2QYT49aQfaQL61Xbo7tg0cFkw3mpAoQBA1W7gx2VaeqI64I2nln3Hh1uotzn9B8udWR8BYSMqlPuBC7FfkB3h4USNZBnkMcC4nEG7nriDQe8+Ihf2vTmegn/NVvucDzLlEkdtbzbLQdVzr4tB0= Received: by 10.35.82.15 with SMTP id j15mr1021960pyl; Mon, 01 May 2006 09:42:26 -0700 (PDT) Received: by 10.35.59.7 with HTTP; Mon, 1 May 2006 09:42:26 -0700 (PDT) Message-ID: <4dd1f3f00605010942u6ffd0f9fkce2c533adcf7caa5@mail.gmail.com> Date: Mon, 1 May 2006 09:42:26 -0700 From: "Weldon Washburn" To: harmony-dev@incubator.apache.org Subject: Re: [classlib] gnuclasspathadapter -- current status on getting specJVM98 to run In-Reply-To: <44562A19.40104@dellroad.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <4dd1f3f00604301838o6765b7arbe5b3e16a772e7d2@mail.gmail.com> <44562A19.40104@dellroad.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 5/1/06, Archie Cobbs 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 (=A72.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.co= m > > --------------------------------------------------------------------- > 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