harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [DRLVM] MMTk vmmagic classes, can someone w/ compiler experience help me?
Date Fri, 09 Jun 2006 14:02:30 GMT
Ok, actually I meant to write:
         int xx = 33;
         Address a1 = Address.creat(xx);
so that the bytecode sequence has no stuff for object new. JIT only
needs to recognize Address.creat() as an intrinsic for compilation
without bytecode rewrite.

And yes, I agree that an Address can be only an address in semantics
if that's desirable.

Thanks,
xiaofeng

On 6/9/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> On 6/9/06, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > Clever trick. But I don't understand why you want to create the
> > Address object at all.
>
> hmm... please read my example again.  I do not create an Address
> object.   And the call to invokespecial is nop'ed.
>
> > You can probably just invoke a method of
> > Address to generate an Address object reference, and the method
> > "invoke" bytecode can be identified by the JIT compiler easily and
> > replaced by a nop or whatever proper. In this way, the Address object
> > reference can be used directly as an "object reference", i.e., object
> > pointer.
>
> Well actually in what I propose, instances of Address are always an
> "int".  Note that the JIT never has GC maps for ints.  If  I
> understand vmmagic correctly, instances of Address are only used for
> pointer arithmetic.  They are never used as reference pointers.  To
> use an Address as a reference pointer, you must convert it back to an
> ObjectReference.
>
> >
> > Thanks,
> > xiaofeng
> >
> > On 6/9/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > > All,
> > >
> > > I am hoping someone who has worked on compilers can actually do the
> > > JIT modifications.  I don't have much experience in compilers.
> > >
> > > I am trying to get MMTk write barriers integrated into Harmony DRLVM.
> > > I came up with the following scheme.  I don't know if it is correct.
> > > It would be great if someone from the MMTk crowd looked at it.  If it
> > > helps, I can also post this message on Jikes/MMTk mailing list.
> > >
> > > Build a shim between the DRLVM class loader and Jitrino.JET.  The shim
> > > would contain a lookup table that would map _local_ variables of
> > > specific types to int.  In particular, the shim would re-map local
> > > variables of the below types to int:
> > >
> > > Address
> > > Extent
> > > Offset
> > > Word
> > >
> > > The reason for the shim is to avoid modifying the class loader.  This
> > > should reduce the maintenance burden.
> > >
> > > Java source code that creates objects of the above classes is a now a
> > > problem.  For example, Java source code that does:
> > >
> > >         int xx = 33;
> > >         Address a1 = new Address(xx);
> > >
> > > Translates to the following bytecode:
> > >
> > >         bipush 33
> > >         istore_1
> > >         new     //class Address
> > >         dup
> > >         iload_1
> > >         invokespecial   //Method "<init>": (I)V
> > >         astore_2
> > >
> > > Basically the JIT needs to special case "new".  If it is a new of
> > > class Address/Extent/Offset/Word, substitute nop for the new bytecode.
> > >  If new has been substituted, then replace the following "dup" with a
> > > nop.  Leave iload_1 alone.  Nop invokespecial.  If the new was nop'ed,
> > > replace astore_2 with istore_2.
> > >
> > > The bytecode sequence the JIT really sees is now:
> > >
> > >         bipush 33
> > >         istore_1
> > >         nop                     //new   //class Address
> > >         nop                     // dup
> > >         iload_1
> > >         nop                     //invokespecial //Method "<init>": (I)V
> > >         istore_2                        //astore_2
> > >
> > > Another example:
> > >
> > >         int xx = 33;
> > >         Address a1 = new Address(xx);
> > >         int kk = a1.toInt();
> > >
> > > Translates to bytecode that looks like:
> > >
> > >
> > >         bipush 33
> > >         istore_1
> > >         new     //class Address
> > >         dup
> > >         iload_1
> > >         invokespecial   //Method "<init>": (I)V
> > >         astore_2
> > >         <<<<<<<<<<<<<<<<<<<
new code starts here
> > >         aload_2
> > >         invokevirtual   //Method toInt(V)I
> > >         istore_3
> > >
> > > All the bytecode down to astore_2 has already been described in the
> > > first example.  The additional bytecode would be magically remapped by
> > > the JIT to:
> > >
> > >         iload_2         // aload_2
> > >         nop             // invokevirtual        //Method toInt(V)I
> > >         istore_3
> > >
> > > Equivalent mappings will be needed for the rest of the methods of
> > > class Address as well as Extent, Offset and Word.
> > >
> > > Will the above work?  Thoughts?
> > >
> > >
> > >
> > >
> > > --
> > > 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
>
>
> --
> 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
>
>

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


Mime
View raw message