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
|