On 7/10/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Weldon,On 7/9/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > All, > > As a first step to improving DRLVM's GC/VM interface, it would be > great to cleanup drlvm/trunk/vm/include/open/vm_gc.h and gc.h. > Basically the concept is to start by removing unused APIs and fixing > the comments. This is a good idea. The interface is subject to be tested with different GC algorithms. > A second step would be to modify these files to accommodate different > GCs such as MMTk. May be reorder the two steps? since only after we have other GCs plugged in can we finalize the cleanup. Of course we can do some cleanup based on common sense and experience. > To start the discussion, below are some initial comments on gc.h > > GCExport void gc_test_safepoint(); > The comments associated with this API are vague and confusing. "The > GC may ignore this, or it may force a root set enumeration, or it may > execute a full GC. Questions for the debugger folks: Is this > interface really needed? When does it actually have to do something? > If a full GC arbitrarily happens when this API is called, will the > debugger work as expected? One interpretation of the comments is that > "void gc_test_safepoint() {}" satisfies the requirements and everyone > is happy. I don't really understand this API. I guess the intention is to allow the VM to ping the GC whenener it feels appropriate at a safepoint, so that the GC can take some action accordingly. Basically it gives GC a hook point when GC can do virtually anything. But I don't understand when is proper for VM to ping GC arbitrily without concrete contract between them. Maybe some parameter is desirable to convey the meanly contract information, e.g., sometime the VM may ask GC to compact its heap. This API is too vague to be an API.
IMHO, the function was added for testing purposes. Safe point is the place where enumeration is possible. The call could be used by specific GC which validates correctness of the VM enumeration code. Instead of expensive garbage collection some simplier validation pass can be used.
> GCExport void gc_add_root_set_entry_managed_pointer(); > I looked at the code. Its in gc_for_vm.cpp. I remember writing code > very similar to this function to support ECMA CLI. ECMA CLI needs to > handle the situation where an optimizing compiler leaves an interior > pointer to an array pointing just one past the last element. > Understand that the optimizing compiler is smart enough not to use > this bad pointer but in ECMA CLI it could get reported to the GC. > Since none of this happens in Java, how about dumping this API? We > should replace it with gc_add_root_set_entry(). Thoughts? I agree. It may be useful for future optimizations but it is strange to have an API for optimization-only purpose.
Agree. Get rid of it.
> GCExport Managed_Object_Handle gc_alloc_pinned(); > This API is currently unused. How about we dump it for now? (NOTE: > MMTk has the concept of "immortal space". Immortal space is never > collected, never moved, only traced. Maybe we need an immortal space > kind of API instead??) hmm. I would prefer keeping it. The allocation mechanism is somehow orthogonal to the space orginization. We used it for large object allocation, which is not immortal but pinned. It is weird that gc_pinned_alloc is actually used. Is there some misspelling in the header file?
Pinned forever objects are lead to heap fragmentation and require malloc-like management. It is generally bad idea to have this kind of objects. But it is better then to allocate objects and pin them forever. Immortal space is even more dangerous, it leads to controlled memory leak. What kind of objects should be place in it? Thinking of unloading of unused classloaders - the place is definetly not for class objects. The function is not used for now and can be emulated via alloc + pin. No objection to strip it. It can be added again when it is needed.
> GCExport void gc_write_barrier(Managed_Object_Handle p_base_of_obj_with_slot); > This is a difficult API. For starts, it only applies to write > barriers written in C/asm. Its not usable by MMTk. "C" Write > barriers that also need the ref ptr that gets written to heap will > need to call a different API. That is, unless the JIT can *inline* > random chunks of C/asm and optimize across the call boundary. A hard > and ugly thing to have to do! Since old ORP generational GC and also > SableVM GC only use the above API, my vote is to leave this API "as > is" for now. Agreed. This is too specific to be a reasonable API.
I would like to keep this API. As we talking about C interfaces, this C interfaces can be used by C garbage collector. I know two places where the function feets perfectly: object_clone and array_copy. If C garbage collector provides that function the code is simple - do the copying and call the function. If not, number of per-slot replacing write barriers should be called, which is quite slow for C garbage collector. In all other places in VM use of this function should be discouraged. Regards, -- Ivan --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
