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.Classes and > > 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
