harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [DRLVM][Helper inlining] GC write barrier inline?
Date Wed, 29 Nov 2006 11:33:11 GMT
Adding a write barrier fast path in current development stage is IMHO
a good idea.
+1
--
Ivan

On 11/29/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
>

-- 
Ivan
Intel Enterprise Solutions Software Division

Mime
View raw message