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 07:49:58 GMT
Clever trick. But I don't understand why you want to create the
Address object at all. 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.

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


Mime
View raw message