From dev-return-28637-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Fri Jul 27 12:44:53 2007 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 44705 invoked from network); 27 Jul 2007 12:44:52 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 27 Jul 2007 12:44:52 -0000 Received: (qmail 7248 invoked by uid 500); 27 Jul 2007 12:44:51 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 7008 invoked by uid 500); 27 Jul 2007 12:44:51 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 6999 invoked by uid 99); 27 Jul 2007 12:44:51 -0000 Received: from Unknown (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jul 2007 05:44:50 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of alexei.fedotov@gmail.com designates 64.233.166.181 as permitted sender) Received: from [64.233.166.181] (HELO py-out-1112.google.com) (64.233.166.181) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jul 2007 12:44:46 +0000 Received: by py-out-1112.google.com with SMTP id a73so1651064pye for ; Fri, 27 Jul 2007 05:44:25 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lSj/MC+sLRsKz8xlP/DPWaMUOvn+g5tcX5ee4OK1+dJqgSJeQvvWpK3DqALB6b/Me7Xb1thbSQpwT3M6qIxzou9ahOZav5mmgeXhgVphjiuhL6kUQGH88mqVOIQ6OBtn5lwR5zTapB2w1y7oMCj1yLmfG0ai7RdlG5vCbbmMHrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Nb2Lr8MAAb0SbIbNdy1lgD73e0QsqfbLT42FpHTmuENVNAR7O9jq3xjIQLJFompxhy8cpxkJOpqO3JAso2DyYIVOO/q7hWUrjOWiEHlM5t4d1ilpeeUQdgfR3ibaIU0LEtVqxI6gC9ywO5hvSCseOSoMuB/SBlQ3IKBwZacYJw8= Received: by 10.65.183.7 with SMTP id k7mr1150326qbp.1185540264974; Fri, 27 Jul 2007 05:44:24 -0700 (PDT) Received: by 10.64.196.8 with HTTP; Fri, 27 Jul 2007 05:44:24 -0700 (PDT) Message-ID: Date: Fri, 27 Jul 2007 16:44:24 +0400 From: "Alexei Fedotov" To: dev@harmony.apache.org Subject: Re: [jira] Commented: (HARMONY-4538) [drlvm][verifier][regression] Two tests on invokevirtual instruction started to fail after verifier switch. In-Reply-To: <906dd82e0707270516g121c0bf8q86e24185c81946d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <504418.1185372751394.JavaMail.jira@brutus> <12505728.1185434911378.JavaMail.jira@brutus> <906dd82e0707270516g121c0bf8q86e24185c81946d@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org Mikhail, Pavel (P), Pavel (R), me and Gregory has discussed this problem. We agreed that both approaches make sense. Here are three reasons why it is better to throw VerifyError during verification stage compared to runtime check outlining the differences between VerifyError and IllegalAccessError. * Specification of VerifyError says that. * VerifyError should be thrown before any bytecode of the method is executed while IllegalAccessError is thrown when a problematic instruction is executed. * You may turn on/off IllegalAccessError in runtime using SetAccessible reflection call, and this shouldn't be true for problems that cause VerifyError. If you are not convinced with this feel free to implement the behavior as you like since the impact of the solution is not great. On 7/27/07, Mikhail Loenko wrote: > Though this bugs needs to be fixed, I have a feeling that verifer is not > the right place for this check: > > It checks the following: if 'a' extends 'b' and 'b' has protected > method (or field) 'm', > and 'a' and 'b' have different packages then you can't call e.g. > 'new b().m()' from a method of class 'a' > > If you try you should get VerifyError. > > old verifier has this check, I've implemented it in the new one as well, > but i'm reluctant to integrate it since these access checks are not specific > for verifier and all other access check are implemented in runtime > > For example if in the example above 'm' is package-access, then > IllegalAccessError > is thrown. > > I suggest that we don't fix verifier's behavior but instead move this > check to a more > natural place > > Thanks, > Mikhail > > > 2007/7/26, Mikhail Loenko (JIRA) : > > > > [ https://issues.apache.org/jira/browse/HARMONY-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515613 ] > > > > Mikhail Loenko commented on HARMONY-4538: > > ----------------------------------------- > > > > evaluation: this one should be fixed as well > > > > > [drlvm][verifier][regression] Two tests on invokevirtual instruction started to fail after verifier switch. > > > ----------------------------------------------------------------------------------------------------------- > > > > > > Key: HARMONY-4538 > > > URL: https://issues.apache.org/jira/browse/HARMONY-4538 > > > Project: Harmony > > > Issue Type: Bug > > > Components: DRLVM > > > Reporter: Pavel Pervov > > > Assignee: Mikhail Loenko > > > > > > The tests > > > vm/jvms/instructions/invokeReturn/invokevirtual/invokevirtual13/invokevirtual1304/invokevirtual1304 and > > > vm/jvms/instructions/invokeReturn/invokevirtual/invokevirtual13/invokevirtual1309/invokevirtual1309 > > > started to fail. > > > Tests check that protected and private methods of superclass located in package different from the class can't be called. > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > > -- With best regards, Alexei, ESSD, Intel