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