harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Wed, 29 Nov 2006 14:25:58 GMT
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 <xiaofeng.li@gmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message