harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject [DRLVM] GC/VM interface discussion
Date Sat, 08 Jul 2006 16:11:47 GMT

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.

A second step would be to modify these files to accommodate different
GCs such as MMTk.

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.

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?

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??)

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.

Weldon Washburn
Intel Middleware Products Division

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message