On 11/29/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
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?
I think the helpers are GC specific, so it makes sense to put it into
its owning GC's directory. Yes, this write barrier will stay in GCv5
directory.
Mikhail Fursov has made very good contribution as to Java helpers
framework in his patch. I think it makes sense for the write barrier
to follow the conventions there, including the the interaction with
vmmagic.
Thanks,
xiaofeng
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
