I've introduced class unloading test into harmony-2000 attachments: Test_unloading_native_lib.zip. This test is drlvm class unloading implementation specific.
Aleksey. On 11/3/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
Weldon, >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. Vtables are not affected in native resource cleanup patch (no change from c struct to object). GCV4: There is some code cleanup and native resource cleaning in gcv4. The same will be done for gc_gen and gc_cc by GC people with separate JIRA, becuse it could affect some performance problems. I have updated patches to the final versions: native_sources_cleanup_upd.patch, auto_unloading_upd.patch. So, I suppose native_sources_cleanup_upd.patch is ready for comit. Aleksey. 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 > >
