harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [drlvm] Class unloading support - tested one approach
Date Thu, 09 Nov 2006 18:29:26 GMT
Etienne Gagnon wrote:
> Salikh Zakirov wrote:
>>   7) let the GC finish collection and reclaim unreachable objects -- this reclaims
java objects
> 
> Just a bit of a warning...  This should be integrated within the
> weak/soft/phantom + finalization framework.  We definitely don't want
> the native resources of a class loader to be freed and later have
> finalization revive the class loader...  :-)

Agreed. "Revival" of classloaders should be done after "revival"
of objects in finalization queue.

I think this scheme can be implemented by introducing one additional GC->VM callback (vm_trace_complete),
which would be called right after GC completed the trace. The call sequence will be as follows:

       GC                                                        VM
        |---------------------------------------> vm_enumerate_root_set()
        | gc_add_root_set_entry()<-------------------------------|
        | gc_add_root_set_entry()<-------------------------------|
        | gc_add_root_set_entry()<-------------------------------|
        |<- - - - - - - - - - -return from vm_enumerate_root_set()
        |                                                        |
   [trace heap]                                                  |
        |                                                        |
        |---------------------------------------> vm_trace_complete()
        | gc_add_root_set_entry()<-------------------------------|
        | gc_add_root_set_entry()<-------------------------------|
        |< - - - - - - - - - - - return from vm_trace_complete()-|
        |                                                        |
   [trace heap from new roots,                                   |
     if there are any]                                           |
        |---------------------------------------> vm_trace_complete()
        |< - - - - - - - - - - - return from vm_trace_complete()-|
        |
   [no retrace, as no new roots were received]
        |
   [reclaim space]
        |

Additionally, even finalization itself can be moved out of GC responsibility,
using this interface and one additional function to query if the object
was already reached or not.

> [Luckily, nothing special needs to be done for JNI code;
> Call<TYPE>StaticMethod does require a native reference to a class
> object.  Yay! ]

Unluckily, something needs to be done for JVMTI. It has a function IterateOverHeap
which is supposed to iterate over both reachable and unreachable objects by scanning
heap linearly.

Thus, if the respective capability (can_tag_objects) has been requested on the VM startup,
the GC must run in a special mode and zero out all unreachable objects, because the unreachable
object may loose its descriptor (VTable) at any time, and GC will not be able even to know
its size.

This will prevent some optimizations, like not reclaiming short free areas in unmovable space,
and require some special attention from the GC developers. OTOH, gc_cc already has a special
mode
(-Dgc.heap_iteration=1) to support iteration even before class unloading is implemented.


Mime
View raw message