On 6/4/06, Alex Astapchuk <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
