From harmony-dev-return-18710-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Fri Nov 10 15:17:40 2006 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 8154 invoked from network); 10 Nov 2006 15:17:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Nov 2006 15:17:39 -0000 Received: (qmail 57461 invoked by uid 500); 10 Nov 2006 15:17:45 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 57415 invoked by uid 500); 10 Nov 2006 15:17:45 -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 57406 invoked by uid 99); 10 Nov 2006 15:17:45 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Nov 2006 07:17:45 -0800 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=SPF_HELO_PASS,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted nor denied by domain of geir@pobox.com) Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Nov 2006 07:17:30 -0800 Received: from [192.168.1.104] (unknown [67.86.14.213]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 130615193B for ; Fri, 10 Nov 2006 10:17:08 -0500 (EST) Message-ID: <45549800.9020203@pobox.com> Date: Fri, 10 Nov 2006 10:17:20 -0500 From: "Geir Magnusson Jr." Reply-To: geir@pobox.com User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] Class unloading support References: <5836de490610240251p120dfa56x736fbb5eb1898aca@mail.gmail.com> <4dd1f3f00610270707q33e759fel636e9f4afe425193@mail.gmail.com> <4546F7EF.4030103@anu.edu.au> <4dd1f3f00610310813g7bf8d7d8nb38b242d19c8dfc@mail.gmail.com> <45480612.5020407@anu.edu.au> <5836de490610312059nec6e191me68f83c88df82f9@mail.gmail.com> <5836de490610312120i6e521dbewd0d36fe5eb7b0d0c@mail.gmail.com> <5836de490611020456j2109a177w4baffd9b1266d19e@mail.gmail.com> <4dd1f3f00611020909g1e41d768l92c4a8ebf2a9acff@mail.gmail.com> <4dd1f3f00611091423u31f05581y532d6fa9831510b0@mail.gmail.com> <5836de490611100048q36d74e6bn919339e19eac019f@mail.gmail.com> In-Reply-To: <5836de490611100048q36d74e6bn919339e19eac019f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hang on - we aren't going to consider this patch quite yet, are we? We have a very active and fruitful discussion going on regarding alternate approaches? geir Aleksey Ignatenko wrote: > Weldon, I have attached updated patch to H-2000: > cleanup_sources_1558_merged.patch. > Please, see comments. > > Aleksey. > > > On 11/10/06, Weldon Washburn wrote: >> >> Aleksey, >> I tried to apply native_sources_cleanup_upd.patch. svn HEAD has changed >> and >> the patch no longer works. Part of the problem is that JIRA 1558 has >> been >> committed. In addition to the below issues, I posted comments to >> JIRA HARMONY-2000. >> >> >> On 11/2/06, Weldon Washburn wrote: >> > >> > Aleksey, >> > >> > Excellent step forward -- breaking the patch into two pieces. This >> made >> > the patch(es) much more readable. >> > >> > I glanced at native_sources_cleanup.patch. It looks like code for >> > alloc/dealloc vtables and jitted code blocks. The original patch made >> > vtables into objects. Will native_sources_cleanup need to change if >> vtables >> > are normal C structs instead? Also, I see reference to path >> .../gcv4/... I >> > guess this will need to change to support gc_gen and gc_cc. >> > >> > Once you get native_sources_cleanup.patch in good shape, I have no >> problem >> > committing it. >> > >> > If there is no other debate on class unloading design, I will call >> for a >> > vote in a seperate email. >> > >> > >> > >> > On 11/2/06, Aleksey Ignatenko wrote: >> > > >> > > Hi, everyone. >> > > >> > > I've splitted Harmony-2000 (see details: >> > > http://issues.apache.org/jira/browse/HARMONY-2000) patch with >> automatic >> > > class unloading implementation into 2 independent parts: >> > > 1. cleaning native resources (native_sources_cleanup.patch). >> > > 2. automatic unloading design implementation (auto_unloading.patch). >> > > >> > > The first part is independent for all class unloading designs and >> could >> > > be >> > > commited. The second part is class unloading design implementation >> (the >> > > best >> > > class unloading approach is discussed now). >> > > >> > > I propose to commit native_sources_cleanup.patch and continue class >> > > unloading development with minimal requirements on drlvm. >> > > >> > > Aleksey. >> > > >> > > >> > > On 11/1/06, Aleksey Ignatenko wrote: >> > > > >> > > > Oops, sorry, misprinted in my suggestion: >> > > > if (cl->IsBootstrap() *|| >> > > *env->b_VTable_trace_is_not_supported_by_GC) >> > > > >> > > > { >> > > > vm_enumerate_jlc(c); >> > > > if (c->vtable) >> > > > >> vm_enumerate_root_reference((void**)&c->vtObj, >> > > > FALSE); >> > > > } >> > > > >> > > > Aleksey. >> > > > >> > > > On 11/1/06, Aleksey Ignatenko < aleksey.ignatenko@gmail.com> >> wrote: >> > > > > >> > > > > Weldon, >> > > > > >> > > > > >A question for all involved. Is it possible to somehow make it >> > > appear >> > > > > that >> > > > > >the new objects related to unloading (VTable, ClassLoader, >> > > etc) are >> > > > > always >> > > > > >reachable and thus never collected? I am trying to figure out a >> > > way to >> > > > > make >> > > > > >integration of class unloading independent of correct support >> > > inside >> > > > > the GC >> > > > > >and JIT. This option could be a command line switch or compile >> > > time >> > > > > option. >> > > > > >> > > > > I agree with Robin: >> > > > > >Simple. Keep a list or table of these objects as part of the >> root >> > > set. >> > > > > >Enumerate it optionally depending on a command line option. >> > > > > >> > > > > Details: you can see from Harmony-2000 patch, that this is done >> for >> > > > > Bootstrap classes already. If you look at >> root_set_enum_common.cpp >> > > (with the >> > > > > patch applied) vm_enumerate_static_fields() function, there is >> line: >> > > > > if (cl->IsBootstrap()) >> > > > > { >> > > > > vm_enumerate_jlc(c); >> > > > > if (c->vtable) >> > > > > >> > > vm_enumerate_root_reference((void**)&c->vtObj, >> > > > > FALSE); >> > > > > } >> > > > > else >> > > > > { >> > > > > vm_enumerate_jlc(c, true/*weak*/); >> > > > > } >> > > > > You can see, that there are strong roots to Bootstrap >> j.l.Classesand >> > > > > their VTable objects. So I suppose, that it would be very simple >> to >> > > > > propogate strong roots to all other classes (not only Bootstrap), >> > > something >> > > > > like: >> > > > > if (cl->IsBootstrap() *&& >> > > > > env->b_VTable_trace_is_not_supported_by_GC*) >> > > > > { >> > > > > vm_enumerate_jlc(c); >> > > > > if (c->vtable) >> > > > > >> > > vm_enumerate_root_reference((void**)&c->vtObj, >> > > > > FALSE); >> > > > > } >> > > > > where *b_VTable_trace_is_not_supported_by_GC *is flag which is >> set >> > > > > according to used GC. This will force switching off any class >> > > unloading >> > > > > support. >> > > > > >> > > > > Aleksey. >> > > > > >> > > > > On 11/1/06, Robin Garner wrote: >> > > > > > >> > > > > > Weldon Washburn wrote: >> > > > > > > On 10/30/06, Robin Garner < robin.garner@anu.edu.au > wrote: >> > > > > > >> >> > > > > > >> Weldon Washburn wrote: >> > > > > > >> > On 10/27/06, Geir Magnusson Jr. < geir@pobox.com> wrote: >> > > > > > >> >> >> > > > > > >> >> >> > > > > > >> >> >> > > > > > >> >> Weldon Washburn wrote: >> > > > > > >> >> > Steve Blackburn was in Portland Oregon today. I >> mentioned >> > > the >> > > > > > idea >> > > > > > >> of >> > > > > > >> >> > adding a reference pointer from object to its >> > > j.l.Classinstance. >> > > > > > >> >> MMTk >> > > > > > >> >> > was >> > > > > > >> >> > not designed with this idea in mind. It looks like you >> > > will >> > > > > > need to >> > > > > > >> >> fix >> > > > > > >> >> > this part of MMTk and maintain it yourself. Steve did >> not >> > > > > > seem >> > > > > > >> >> thrilled >> > > > > > >> >> at >> > > > > > >> >> > adding this support to MMTk code base. >> > > > > > >> >> > > > > > >> Actually I think the answer may have been a little garbled >> > > along >> > > > > > the way >> > > > > > >> here: MMTk is not a memory manager *for* Java, it is >> simply a >> > > > > > memory >> > > > > > >> manager. We have been careful to eliminate >> language-specific >> > > > > > features >> > > > > > >> in the heap that it manages. MMTk has been used to >> manage C# >> > > (in >> > > > > > the >> > > > > > >> Rotor VM) and was being incorporated into a Haskell runtime >> > > until I >> > > > > > ran >> > > > > > >> out of time. >> > > > > > >> >> > > > > > >> Therefore, MMTk knows nothing about the concept of class >> > > unloading, >> > > > > > or >> > > > > > >> java.lang.Class . >> > > > > > >> >> > > > > > >> >> How does MMTk support class unloading then? >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > MMTk has no special support for class unloading. This may >> > > have >> > > > > > >> > something to >> > > > > > >> > do with the entire system being written in Java thus class >> > > > > > unloading >> > > > > > >> come >> > > > > > >> > along for free. If there needs to be a modification to >> > > support >> > > > > > special >> > > > > > >> > case >> > > > > > >> > objects in DRLVM, someone will need to fixup MMTk and >> provide >> > > > > > onging >> > > > > > >> > support of this patch in Harmony. I have zero idea how >> big >> > > this >> > > > > > effort >> > > > > > >> > would be. It would also be good to hear what the impact >> > > will be >> > > > > > on >> > > > > > >> GCV5. >> > > > > > >> >> > > > > > >> MMTk implements several algorithms for retaining the >> reachable >> > > > > > objects >> > > > > > >> in a graph and recycling space used by unreachable ones. It >> > > relies >> > > > > > on >> > > > > > >> the host VM to provide a set of roots. It supports several >> > > > > > different >> > > > > > >> semantics of 'weak' references, including but not >> confined to >> > > those >> > > > > > >> required by Java. >> > > > > > >> >> > > > > > >> If you can implement class unloading using those (which the >> > > current >> > > > > > >> > > > > > >> proposal does), then MMTk can help. >> > > > > > >> >> > > > > > >> If you want to put a pointer to the j.l.Class in the object >> > > header, >> > > > > > MMTk >> > > > > > >> will not care, as it has no way of knowing. If you put an >> > > > > > additional >> > > > > > >> pointer into the body of every object, then MMTk will see it >> as >> > > > > > just >> > > > > > >> another object to scan. >> > > > > > >> >> > > > > > >> Remember MMTk is a memory manager, not a Java VM! >> > > > > > >> >> > > > > > >> >> > > > > > >> Conversely, supporting some exotic class unloading mechanism >> in >> > > >> > > > > > MMTk >> > > > > > >> shouldn't be hard and wouldn't deter me from trying it out. >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > Robin, it would be great if you can get MMTk to support this >> > > class >> > > > > > > unloading >> > > > > > > effort. My main concern is the ongoing maintenance of MMTk >> > > class >> > > > > > unloading >> > > > > > > support. >> > > > > > >> > > > > > I haven't seen any proposal that requires MMTk to be modified, >> so >> > > it's >> > > > > > a >> > > > > > moot point at the moment. >> > > > > > >> > > > > > > A question for all involved. Is it possible to somehow make >> it >> > > > > > appear that >> > > > > > > the new objects related to unloading (VTable, ClassLoader, >> > > > > > etc) are >> > > > > > > always >> > > > > > > reachable and thus never collected? I am trying to figure >> out >> a >> > > way >> > > > > > to >> > > > > > > make >> > > > > > > integration of class unloading independent of correct support >> > > inside >> > > > > > the GC >> > > > > > > and JIT. This option could be a command line switch or >> compile >> > > time >> > > > > > >> > > > > > > option. >> > > > > > >> > > > > > Simple. Keep a list or table of these objects as part of the >> root >> > > >> > > > > > set. >> > > > > > Enumerate it optionally depending on a command line option. >> > > > > > >> > > > > > cheers, >> > > > > > Robin >> > > > > > >> > > > > >> > > > > >> > > > >> > > >> > > >> > >> > >> > -- >> > Weldon Washburn >> > Intel Enterprise Solutions Software Division >> > >> >> >> >> -- >> Weldon Washburn >> Intel Enterprise Solutions Software Division >> >> >