From dev-return-35861-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Mon Jan 05 04:09:08 2009 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 36379 invoked from network); 5 Jan 2009 04:09:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Jan 2009 04:09:08 -0000 Received: (qmail 81457 invoked by uid 500); 5 Jan 2009 04:09:07 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 81430 invoked by uid 500); 5 Jan 2009 04:09:07 -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 81419 invoked by uid 99); 5 Jan 2009 04:09:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 04 Jan 2009 20:09:07 -0800 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 xiaofeng.li@gmail.com designates 209.85.218.15 as permitted sender) Received: from [209.85.218.15] (HELO mail-bw0-f15.google.com) (209.85.218.15) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Jan 2009 04:08:56 +0000 Received: by bwz8 with SMTP id 8so16593077bwz.12 for ; Sun, 04 Jan 2009 20:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=lTYrts8TKF5zqP0JKtLpGqGG4JrxFp4q7MhYnPhgsT8=; b=lPNp4xd6Aw2KE+J0j8ivX57hBzvT4CYFnhLHbV/oiL2QquL022pHOtmlDpaqFIvL5u fu6rgRbHUQVnW1SajdcehsS1kwayVezudJRzgU8iVVOz1B7ErcwgK5a/fiMtLaNDjxzX HvUUOHmwE8Apq+YC0PPceER8nuZ22D3vNRZps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=sK+3XAMhlWPcUrkXAUYgU1EPIASMx1++3YiDY7wCAJRJnLmAaQY8DKGnl2+RI4yaLJ 27B0slGqD57MjBQsmwRnwo10WR4uQYxfLzOGQ0vyZYn3TBI8Iy0VRrCBI5gtTaFiSli1 oLt1ZWLNcsNbQySGwVS5VkuedjCekYVHWpthE= Received: by 10.181.137.13 with SMTP id p13mr7930896bkn.173.1231128513479; Sun, 04 Jan 2009 20:08:33 -0800 (PST) Received: by 10.181.148.6 with HTTP; Sun, 4 Jan 2009 20:08:33 -0800 (PST) Message-ID: <9623c9a50901042008k24767f64y665a3b6763b5efa0@mail.gmail.com> Date: Mon, 5 Jan 2009 12:08:33 +0800 From: "Xiao-Feng Li" To: dev@harmony.apache.org Subject: Re: [class loading] what's the expected behavior when a static method is invoked before its class is initialized? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9623c9a50901032259r2b8fdcfg7890200de0ff9cee@mail.gmail.com> <9623c9a50901040326s5896c714ub389516138b68341@mail.gmail.com> <3b3f27c60901040920n6d161af5la840240d30a86818@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Jan 5, 2009 at 5:12 AM, Ian Rogers wrote: > 2009/1/4 Nathan Beyer > >> Could any of the IBM folks on the list get some advice from some class >> loader experts? >> >> -Nathan >> > > Hi Nathan, > > from reading the description I can describe how Jikes RVM avoids this > problem (I'm not an IBM VME expert and I've not run the test case to check > that Jikes RVM passes it). In Jikes RVM we have two variants of all calls, > ones to unresolved methods and ones to resolved methods. Unresolved calls > are to classes whose initializer hasn't yet been run. If two threads are > calling a static method the first will resolve it and in the process acquire > a lock, the second thread must wait for the lock before it can attempt to > resolve the method (at which point it will discover the method was resolved > by the other thread and leave early). Checking for classes being resolved > litters all of the class loader code, and we're slightly proactive in > resolving in the case of reflected methods so that we needn't check for > resolution when performing reflected method invocation (which is now pretty > much unnecessary since [1] where we generate bytecodes at runtime to perform > reflection). An aside, I wrote a paper where I use the class loader as a > test case for optimizations based on stationary/immutable fields specified > via constraints [2], this work specialized the class loader to handle the > resolved case as a class is normally accessed when it is resolved (figures > in the paper). Thanks for the explanation. Let me try to explain the problem we are meeting: 1. A thread invokes a static method createChild of a class Parent. It causes class Parent be initialized. 2. In Parent's initialization, it creates an array of class Child. It leads to class Child be initialized. 3. In Child's initialization, it invokes Parent.createChild() to initialize a static field ROOT. This leads to re-entrance of Parent initialization. 4. The thread finds Parent is under initialization by itself, it quits the initialization process and invokes Parent.createChild(). 5. This invocation should not be permitted by the VM spec, and we don't know how to deal with it. It can't wait for the initialization process finished, because it is in the path of the initialization. It has to do something to proceed with the initialization. Below is the code of the micro test. Chunrong, please correct me if my understanding is inaccurate. So my suggestion is to ignore the static method invocation for the class under initialization... public class Main { public static void main(String[] args) { Child c = Parent.createChild(); System.err.println(c); System.err.println(Child.ROOT); } } class Parent { private static final Child[] childCache = new Child[5]; public static Child createChild(){ return childCache[0]; } } class Child { public static final Child ROOT = Parent.createChild(); } Thanks, xiaofeng > Regards, > Ian Rogers > > [1] > http://icooolps.loria.fr/icooolps2008/Papers/ICOOOLPS2008_paper08_Rogers_Zhao_Watson_final.pdf > [2] http://portal.acm.org/citation.cfm?id=1411746 > -- Managed Runtime Technology Center, Intel