Xiao-Feng,
Your suggestion below makes sense. Have you given any thought where the
Java code should reside in the source tree? GCHelper is a Java class that
looks to be specific to a given GC. Does it end up in gcv5
directory? Also, does it make sense to inherit from vmmagic
"Uninterruptible" class?
On 11/28/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Mikhail Fursov has finished the GC alloc helper inlining, it's
probably time to discuss the inlining for write barrier. Write barrier
is one of the top prioritized candidates for inlining, this is common
in known JVMs, and this is also GCv5's urgent need.
The first version of write barrier code in Java can be something like
this (by following the one for gc_alloc):
public class GCHelper {
static {System.loadLibrary("gc_gen");}
/* NOS (nursery object space) is higher in address than other spaces.
The boundary currently is produced in GC initialization. It can
be a constant in future.*/
public static final Address NOS_BOUNDARY = getNosBoundary();
public static void write_barrier_slot_rem(Address p_slot, Address
p_target) {
/* If the slot is in NOS or the target is not in NOS, we simply
return*/
if( p_slot.GE( NOS_BOUNDARY) || p_target.LT( NOS_BOUNDARY) )
return;
/* Otherwise, we need remember it in native code. */
VMHelper.WriteBarrierSlotRem(p_slot, p_target);
}
private static native Address getNosBoundary();
}
How do you think?
Thanks,
xiaofeng
--
Weldon Washburn
Intel Enterprise Solutions Software Division
