You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/06/09 08:52:37 UTC
[DRLVM] MMTk vmmagic classes, can someone w/ compiler experience help me?
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
Re: [DRLVM] MMTk vmmagic classes,
can someone w/ compiler experience help me?
Posted by Robin Garner <ro...@anu.edu.au>.
Robin Garner wrote:
> Weldon Washburn 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);
>>
> MMTk never creates instances of the unboxed magic types, so this
> shouldn't be a problem.
>
Oh, and 'int' is a bad choice, since it is always 32 bits. These types
should be whatever the natural word length of the target architecture is.
cheers
---------------------------------------------------------------------
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
Re: [DRLVM] MMTk vmmagic classes,
can someone w/ compiler experience help me?
Posted by Robin Garner <ro...@anu.edu.au>.
Weldon Washburn 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);
>
MMTk never creates instances of the unboxed magic types, so this
shouldn't be a problem.
cheers
---------------------------------------------------------------------
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
Re: [DRLVM] MMTk vmmagic classes, can someone w/ compiler experience help me?
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <we...@gmail.com> wrote:
> On 6/9/06, Xiao-Feng Li <xi...@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 <we...@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
Re: [DRLVM] MMTk vmmagic classes, can someone w/ compiler experience help me?
Posted by Weldon Washburn <we...@gmail.com>.
On 6/9/06, Xiao-Feng Li <xi...@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 <we...@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
Re: [DRLVM] MMTk vmmagic classes, can someone w/ compiler experience help me?
Posted by Xiao-Feng Li <xi...@gmail.com>.
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 <we...@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