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/02 07:28:48 UTC
[DRLVM] write barrier -- some preliminary design ideas for Jitrino.JET
All,
I have been reading both MMTK and Jitrino.JET sources with write
barrier design specifically in mind. Below are my current thoughts.
Integrating MMTK with Jitrino.JET. In Compiler::gen_field_op(), use
gen_invoke() to emit a call to
org.mmtk.plan.PlanLocal.writeBarrier(ObjectReference src, Address
slot, ObjectReference tgt, Offset metaDataA, int metaDataB, int mode).
Ditto for Compiler::gen_static_op() Ditto for
Compiler::gen_astore(). Note that PlanLocal is an abstract class
which means a GC algorithm specific subclass of PlanLocal will need to
be involved.
Note that if somebody has a GC written in C, one possibility is to
modify Jitrino.JET as follows. In Compiler::gen_field_op(), use
gen_call_novm() or gen_call_vm() to emit a call to a new runtime
helper function. This new helper function would be written in C and
would embody a substituting write barrier. I don't know if it makes a
difference to the write barrier regarding which version (novm or vm)
is called. Maybe Jitrino.JET guys have comment.
Does the above look correct? Last week, Dan Feinberg mentioned that
he will contact the MMTK/Rotor peole he knows. It turns out that the
MMTK/Rotor port is very similar in nature to the MMTK/DRLVM port at
hand.. Dan, can you give us any update?
--
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] write barrier -- some preliminary design ideas for Jitrino.JET
Posted by Alex Astapchuk <al...@gmail.com>.
Weldon Washburn wrote:
> On 6/4/06, Alex Astapchuk <al...@gmail.com> wrote:
>> 'novm' version is a bit lighter. But the difference is very subtle -
>> one or two instructions. In Jitrino.JET we normally use conservative
>> but safer approach - 'every call to VM may throw exception or lead or
>> GC'.
>
> I think that the only exception that can occur during
> putfield/putstatic/aastore execution is a null exception. If we
> explicitly check for null ref pointer before attempting the write, we
> can rule out exceptions for putfield/putstatic/aastore. I assume
> array bounds check (if any) will happen before attemping a write via
> aastore. I assume all other kinds of exceptions (incompatible class
> casting, public/private field clashes...) will be detected during JIT
> time and the right thing will be done before attempting the
Yes, this is correct. Jitrino.JET does not rely on hardware null
pointer exception. All runtime checks are made explicitly - null ref,
bound checks, etc. So when a PUTFIELD's code executed at runtime,
there will be no null ref - guaranteed.
> write. By design, there will be no GC events during write barrier.
> The bottom line: I think we can "design out" all exceptions for the
> write barrier case. The JET/VM model of designing every escape to VM
> to handle a GC is too simplistic. In the case of write barriers this
> model actually causes substantial confusion. If this scheme can be
> made to work, the overhead will be substantial. Think of JNI involved
> everytime a putfield/putstatic/aastore is executed. Plus think of
> jitted code making a call to the VM. The VM turns around and
> immediately upcalls into MMTk java code to execute the write plus
> write barrier. Note this will be very difficult code to debug.
>
>>
>> Though the Compiler::gen_invoke() may be not the best thing to use.
>> The gen_invoke() was designed to handle only INVOKE* instructions in
>> bytecode. In practice, this means that it expects method arguments to be
>> taken from the operand stack. Surely, we could try to put additional
>> arguments on the operand stack and then call gen_invoke(), but we may
>> overflow the operand stack (in Jitrino.JET it has preallocated size
>> exactly as specified for the method).
>
> I have read enough about Jitrino.JET to see that the above is
> definitely a design problem. Is it possible to add 6 stack slots to
> every JITed method so that there is guaranteed space for the write
> barrier arguments? Let me know if this is not possible and I will
> think about some other schemes. (Maybe someone from the Jikes world
> will tell us how it is done in Jikes compiler!)
This will work. The real max stack depth for a method is obtained
once during Compiler initialization, so there will be no problem to
increase it for every method easily.
>>
>> How about the following: the write barrier function is implemented in C
>> and calls to this function is emitted with gen_call_vm() ? Then the
>> function may either directly call VM's helper/inetrface method - if we
>> have a GC written in C or use JNI to call a Java-written GC.
>> (Hmmm... Though I have a bad feeling about performance if we'll have a
>> JNI call on every PUFIELD/PUTSTATIC/AASTORE...).
>
> Yes it is a bad idea. See earlier comments.
So my feelings were divine. :-)
--
Thanks,
Alex
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] write barrier -- some preliminary design ideas for Jitrino.JET
Posted by Weldon Washburn <we...@gmail.com>.
On 6/4/06, Alex Astapchuk <al...@gmail.com> wrote:
> 'novm' version is a bit lighter. But the difference is very subtle -
> one or two instructions. In Jitrino.JET we normally use conservative
> but safer approach - 'every call to VM may throw exception or lead or GC'.
I think that the only exception that can occur during
putfield/putstatic/aastore execution is a null exception. If we
explicitly check for null ref pointer before attempting the write, we
can rule out exceptions for putfield/putstatic/aastore. I assume
array bounds check (if any) will happen before attemping a write via
aastore. I assume all other kinds of exceptions (incompatible class
casting, public/private field clashes...) will be detected during JIT
time and the right thing will be done before attempting the actual
write. By design, there will be no GC events during write barrier.
The bottom line: I think we can "design out" all exceptions for the
write barrier case. The JET/VM model of designing every escape to VM
to handle a GC is too simplistic. In the case of write barriers this
model actually causes substantial confusion. If this scheme can be
made to work, the overhead will be substantial. Think of JNI involved
everytime a putfield/putstatic/aastore is executed. Plus think of
jitted code making a call to the VM. The VM turns around and
immediately upcalls into MMTk java code to execute the write plus
write barrier. Note this will be very difficult code to debug.
>
> Though the Compiler::gen_invoke() may be not the best thing to use.
> The gen_invoke() was designed to handle only INVOKE* instructions in
> bytecode. In practice, this means that it expects method arguments to be
> taken from the operand stack. Surely, we could try to put additional
> arguments on the operand stack and then call gen_invoke(), but we may
> overflow the operand stack (in Jitrino.JET it has preallocated size
> exactly as specified for the method).
I have read enough about Jitrino.JET to see that the above is
definitely a design problem. Is it possible to add 6 stack slots to
every JITed method so that there is guaranteed space for the write
barrier arguments? Let me know if this is not possible and I will
think about some other schemes. (Maybe someone from the Jikes world
will tell us how it is done in Jikes compiler!)
>
> How about the following: the write barrier function is implemented in C
> and calls to this function is emitted with gen_call_vm() ? Then the
> function may either directly call VM's helper/inetrface method - if we
> have a GC written in C or use JNI to call a Java-written GC.
> (Hmmm... Though I have a bad feeling about performance if we'll have a
> JNI call on every PUFIELD/PUTSTATIC/AASTORE...).
Yes it is a bad idea. See earlier comments.
--
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] write barrier -- some preliminary design ideas for Jitrino.JET
Posted by Alex Astapchuk <al...@gmail.com>.
Weldon,
Weldon Washburn wrote:
> All,
> I have been reading both MMTK and Jitrino.JET sources with write
> barrier design specifically in mind. Below are my current thoughts.
>
> Integrating MMTK with Jitrino.JET. In Compiler::gen_field_op(), use
> gen_invoke() to emit a call to
> org.mmtk.plan.PlanLocal.writeBarrier(ObjectReference src, Address
> slot, ObjectReference tgt, Offset metaDataA, int metaDataB, int mode).
> Ditto for Compiler::gen_static_op() Ditto for
> Compiler::gen_astore(). Note that PlanLocal is an abstract class
> which means a GC algorithm specific subclass of PlanLocal will need to
> be involved.
>
> Note that if somebody has a GC written in C, one possibility is to
> modify Jitrino.JET as follows. In Compiler::gen_field_op(), use
> gen_call_novm() or gen_call_vm() to emit a call to a new runtime
> helper function. This new helper function would be written in C and
> would embody a substituting write barrier. I don't know if it makes a
> difference to the write barrier regarding which version (novm or vm)
> is called. Maybe Jitrino.JET guys have comment.
'novm' version is a bit lighter. But the difference is very subtle -
one or two instructions. In Jitrino.JET we normally use conservative
but safer approach - 'every call to VM may throw exception or lead or GC'.
Though the Compiler::gen_invoke() may be not the best thing to use.
The gen_invoke() was designed to handle only INVOKE* instructions in
bytecode. In practice, this means that it expects method arguments to be
taken from the operand stack. Surely, we could try to put additional
arguments on the operand stack and then call gen_invoke(), but we may
overflow the operand stack (in Jitrino.JET it has preallocated size
exactly as specified for the method).
How about the following: the write barrier function is implemented in C
and calls to this function is emitted with gen_call_vm() ? Then the
function may either directly call VM's helper/inetrface method - if we
have a GC written in C or use JNI to call a Java-written GC.
(Hmmm... Though I have a bad feeling about performance if we'll have a
JNI call on every PUFIELD/PUTSTATIC/AASTORE...).
> Does the above look correct? Last week, Dan Feinberg mentioned that
> he will contact the MMTK/Rotor peole he knows. It turns out that the
> MMTK/Rotor port is very similar in nature to the MMTK/DRLVM port at
> hand.. Dan, can you give us any update?
--
Thanks,
Alex
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