Sorry for the confusion. We are getting ourselves all tangled up with subconversations in this thread. There have been 90+ replies to the original posting.
No patch containing class unloading will be committed until Harmony has a design and the design has been implemented. What is being discussed is a patch that cleans up the malloc/free of C structs that are currently used for class loading. I have looked at the proposed patch. It looks to have low impact on stability. It contains no class unloading code. Its not urgent to apply this patch. I will hold off doing anything until the confusion clears. It might even be better to open a new JIRA titled something like, "classloader malloc/free cleanup". Note there are currently 12 files attached to HARMONY-2000. The patch at issue was split out of the original class unloading patch to isolate independent problems. On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> >> 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 <[EMAIL PROTECTED] > wrote: >> > > > > > >> > > > > > Weldon Washburn wrote: >> > > > > > > On 10/30/06, Robin Garner < [EMAIL PROTECTED] > wrote: >> > > > > > >> >> > > > > > >> Weldon Washburn wrote: >> > > > > > >> > On 10/27/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> 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 >> >> >
-- Weldon Washburn Intel Enterprise Solutions Software Division
