From harmony-dev-return-9917-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Fri Jul 07 15:30:46 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 96127 invoked from network); 7 Jul 2006 15:30:45 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 7 Jul 2006 15:30:45 -0000 Received: (qmail 27365 invoked by uid 500); 7 Jul 2006 15:30:42 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 27320 invoked by uid 500); 7 Jul 2006 15:30:42 -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 27301 invoked by uid 99); 7 Jul 2006 15:30:42 -0000 Received-SPF: pass (hermes.apache.org: domain of a.y.chernyshev@gmail.com designates 64.233.184.233 as permitted sender) Received: from [64.233.184.233] (HELO wr-out-0506.google.com) (64.233.184.233) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Jul 2006 08:30:42 -0700 Received: by wr-out-0506.google.com with SMTP id 69so143926wri for ; Fri, 07 Jul 2006 08:29:21 -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=RLnP8i6TkPjrrgb012jZynOOg56pgl2iRY16ThZqDMBsEVnoIz3/IL13gXmk9FRAXpIdk0wg7N5/Ae509BxOYuXu2LCM3Pmr+wAAjctGtGcX3kOSzeszVa/fN0gbXT1qddAeUJmWMrfaqzu5DbZxM+Xao/Df3LdVZsjXK/Tdlgo= Received: by 10.64.178.8 with SMTP id a8mr2320002qbf; Fri, 07 Jul 2006 08:29:21 -0700 (PDT) Received: by 10.65.73.19 with HTTP; Fri, 7 Jul 2006 08:29:21 -0700 (PDT) Message-ID: <6928c5160607070829l6b0887aen30727fed8c964362@mail.gmail.com> Date: Fri, 7 Jul 2006 19:29:21 +0400 From: "Andrey Chernyshev" To: harmony-dev@incubator.apache.org Subject: Re: [classlib] Is it OK for VM kernel class to call internal classlib API? In-Reply-To: <44AE3661.706@googlemail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6928c5160607041107j4e53ca71q76585ffe6d9106de@mail.gmail.com> <44AE3661.706@googlemail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 7/7/06, Oliver Deakin wrote: > Andrey Chernyshev wrote: > > I was trying to compile the kernel classes set from DRLVM independently > > from the classlib and found it difficult because kernel classes set > > currently have a dependence on the internal classlib API, e.g. > > org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection > > and org.apache.harmony.luni.util.DeleteOnExit classes. > > > > I've found the spec for kernel class org.apache.harmony.kernel.vm.VM > > (l'm looking at > > classlib\trunk\modules\luni-kernel\src\main\java\org\apache\harmony\kernel\vm\VM.java) > > > > assumes that VM is calling excplicitly > > JarURLConnection.closeCachedFiles() > > and DeleteOnExit.deleteOnExit() during VM shutdown. > > > > On the other hand, there is standard API in J2SE called > > java.lang.Runtime.addShutdownHook(Thread) which can be used to specify > > the > > tasks that have to be done during VM shutdown. > > BTW, this is exactly how DRLVM implements these methods in it's > > VM.java. For example, for VM.closeJars() it currently does like: > > > > public static void closeJars() { > > class CloseJarsHook implements Runnable { > > public void run() { > > JarURLConnection.closeCachedFiles(); > > } > > } > > ... > > Runtime.getRuntime().addShutdownHook(new Thread(new > > CloseJarsHook())); > > } > > > > Are there any problems with this approach, should the DRLVM (or other > > Vm's) implement these methods differently? > > There is a potential problem with this approach. The code that is run by the > shutdown hooks is not restricted in its behaviour and the order that the > shutdown hooks are executed in is not guaranteed. If the deleteOnExit() > and/or closeCachedFiles are not the last hooks to be executed, it is quite > possible that a subsequent shutdown hook could try to access files that > have already been deleted. The only way to guarantee that this will > never happen is to make sure that deleteOnExit() and closeCachedFiles() > are called after all shutdown hooks have completed. > > Of course, how this is implemented is down to the VM developer - but > I would strongly recommend not using shutdown hooks for this purpose. Thanks Oliver, this explanation sounds reasonable. If the issue is just in the shutdown hooks order, then, still may be it makes sense to add VM.addClasslibShutdownHook(Runnable) method or something like that, which can be: - used by the classlib to do whatever resource cleanup / shutdown works they need; - guaranteed by VM to be executed always after Runtime's shutdown hooks are done (can be specified in the contract)? This approach looks more universal than having two specific methods cloaseJars() and deletOnExit(). It will also allow VM to do not call internal classlib API explicitly. > > > > > May be it makes sense just to move VM.closeJars() and > > VM.deleteOnExit() methods and their drlvm implementation to the luni > > classlib component, under assumption that they do not really contain > > any VM-specific code? > > The version of VM.java currently under luni-kernel does not contain > any VM specific code either, as all its methods simply return null :) > It does, however, give hints as to how to implement the methods > in the javadoc comments (perhaps it should clarify the reason > for not using shutdown hooks). > > As described above, I think there is a problem with this implementation, > so I would not like to see it used as an example for other VM > developers. > > > I have noticed that the Javadoc comments for the DRLVM implementation > of deleteOnExit() and closeJars() both say: > > /** > * 1) This is temporary implementation > * 2) We've proposed another approach to perform shutdown actions. > */ > > Have I missed the proposal of this other approach, or are the comments > inaccurate? I guess there were no one on the mailing list, this seems to be a history of the past internal discussions within drlvm development team. > > > I guess it will simplify a bit the org.apache.harmony.kernel.vm.VM > > interface as well as would allow to avoid extra dependencies between > > VM and classlib. > > > > IMHO there is no problem for kernel classes to have dependencies on > classlib - they are, after all, just another part of the class library that > happens to get developed separately due to their nature. Actually I thought of the kernel classes being part of VM since they are tied to VM-specific functionality. If this is true, then it may be good if we can keep the interface between VM and classlib "clean", e.g. without dependencies on the API which doesn't appear in J2SE. Thanks, Andrey. > > Regards, > Oliver > > -- > Oliver Deakin > IBM United Kingdom Limited > > > --------------------------------------------------------------------- > 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 > > -- Andrey Chernyshev 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