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 <[EMAIL PROTECTED]> wrote:
On 6/9/06, Xiao-Feng Li <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Weldon Washburn
Intel Middleware Products Division
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
