harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Astapchuk <alex.astapc...@gmail.com>
Subject Re: [DRLVM] write barrier -- some preliminary design ideas for Jitrino.JET
Date Wed, 07 Jun 2006 04:19:10 GMT

Weldon Washburn wrote:
> 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 

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


Mime
View raw message