harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM] write barrier -- some preliminary design ideas for Jitrino.JET
Date Mon, 05 Jun 2006 17:59:40 GMT
On 6/4/06, Alex Astapchuk <alex.astapchuk@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


Mime
View raw message