Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 45002 invoked from network); 28 Oct 2006 17:05:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 28 Oct 2006 17:05:43 -0000 Received: (qmail 54570 invoked by uid 500); 28 Oct 2006 17:05:51 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 54441 invoked by uid 500); 28 Oct 2006 17:05:50 -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 54432 invoked by uid 99); 28 Oct 2006 17:05:50 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Oct 2006 10:05:50 -0700 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of rdasgupt@gmail.com designates 64.233.162.195 as permitted sender) Received: from [64.233.162.195] (HELO nz-out-0102.google.com) (64.233.162.195) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Oct 2006 10:05:38 -0700 Received: by nz-out-0102.google.com with SMTP id z6so825800nzd for ; Sat, 28 Oct 2006 10:05:18 -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:references; b=I/KCPO+8UWr2SDL54IXO7WTHO1HyKSEUJwTzQeeCbI8wwQBzeqHV+yBzQXNThTblw/u8HguxgrtT6NFn5cgzA2z+flljszOWJC53OPIJvdlBOGVtYIrWxXsnimdJ0sUHECOHmATsIfxJPfucGMXcSzOWXmM2kn244sa3Y5Q3kKI= Received: by 10.65.242.10 with SMTP id u10mr1475001qbr; Sat, 28 Oct 2006 10:05:17 -0700 (PDT) Received: by 10.65.203.1 with HTTP; Sat, 28 Oct 2006 10:05:17 -0700 (PDT) Message-ID: <51d555c70610281005k722b9398m3677c828cf579a7e@mail.gmail.com> Date: Sat, 28 Oct 2006 10:05:17 -0700 From: "Rana Dasgupta" To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] Class unloading support In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_38056_12888839.1162055117687" References: <5836de490610240251p120dfa56x736fbb5eb1898aca@mail.gmail.com> <51d555c70610261450w27b9e7a0y981bb1468201153e@mail.gmail.com> <4541FE15.6070106@pobox.com> <51d555c70610270758p532a3479kfa894c8b52ce1dc2@mail.gmail.com> <45422160.90106@pobox.com> <9623c9a50610271647j5fef07d7r30ab4b243880fc63@mail.gmail.com> <4542A24E.9060209@pobox.com> <9623c9a50610271758y5e7f87c9p331c26af3e8b6717@mail.gmail.com> <51d555c70610271835s7304ff95t2fb639161a4f478b@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_38056_12888839.1162055117687 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 10/28/06, Mikhail Fursov wrote: > > On 10/28/06, Rana Dasgupta wrote: > > > > On 10/27/06, Xiao-Feng Li wrote: > > > > > > > > > >Yes. That's also my opinion. The _design_ of class unloading is >the > > > >focus of the discussion. > > > > > > > > I think that before doing an optimization, it is a good idea to > understand > > why and where it is needed, and if the usage scenario fits what the > > software > > is intending to do. So this discussion is not misplaced. I am not very > > comfortable with adding a solution before we have understood the > problem. > > Probably the first step is to create a use case that can be used to see > if > > class unloading is the solution. > > > Rana, I do not understand why do you call class unloading 'an > optimization'. In this case any GC is optimization too. Class > unloading is fundamental feature of > Java language. I would even say that if your application uses custom > classloader and you never thought about class unloading the design of your > application is not complete. > We can never claim that Harmony supports Java 1.5 or even Java 1.2 if it > does not support unloading for classloaders. As for me, this is very > important to have this feature and Aleksey's patch is quite a good > beginning. At least in JIT it does not require any changes at all. >From JLS:- "Rationale: Class unloading is an optimization that helps reduce memory use. Obviously, the semantics of a program should not depend on whether and how a system chooses to implement an optimization such as class unloading.....". And ... "Strictly speaking, it was never essential that the issue of class unloading be discussed by the Java Language Specification, as it is an optimization. However, it is a subtle issue, and so it was mentioned by way of clarification. Unfortunately, misunderstandings arose, aggravated by the the class unloading behavior of JDK 1.1. This behavior was not mandated by the Java Language Specification. Indeed, it contradicted the specification; it was simply a bug. The bug has been fixed in JDK 1.2, and the specification clarified to avoid such misunderstandings in the future." Anyway, I don't want to belabor this point forever, and my opinion is only one among many :-) Rana ------=_Part_38056_12888839.1162055117687--