Ming, > The above is just a consideration for infrastructure. I have already > implemented the write barrier code in jet for some GC developed in C. > It has already been tested and attached file is the patch. Cool ! Thanks for the patch !
I'm not too familiar with GC stuff, but seems you are right and your patch fits all. In case of AASTORE for .jet, as it generates a helper call anyway, the VM can do the job. The statics are all known for GC so they can be easily scanned. (Can GC guys comment on this ?) -- Thanks, Alex
hi, guys The way to use gen_invoke to call a Java write barrier should work, and the better way may be inlining the barrier code. Maybe jet can not do inlining, but jitrino.opt should do it. Alex's idea is not so bad. It is right that the cost will be high if we'll have a JNI call on every PUFIELD/PUTSTATIC/AASTORE, but I think the performance for jet is not very critical, becasue it is not an optimized jit. If we realy care about some methods' performance, we should recompile it using some more powerful jit such as jitrino.opt. In fact, Alex's idea can be implemented as something like a root GC which can dynamically manage the different GC with the same interface. The idea of root GC will actually incur many overhead of indirect calling. I think, if we only care about the static situation with certain information about what gc we use, whether we have write barriers .etc, the direct solution is sure to be the best. But when we consider some dynamic situations, it is not the case. For example, when we change a gc without needs for write barrier to another gc with the needs during runtime, if we do not have help of root GC, we should recompile the method using jet, and if we have root GC, we do not have to recompile it, the changing to a new write barrier function can be finished by root GC interface during the process of loading of the new gc. Of course, recompiling for more powerful optimization is necessary, but it should only be done on some hot methods, and we may not need to recompile all the methods using jet. The above is just a consideration for infrastructure. I have already implemented the write barrier code in jet for some GC developed in C. It has already been tested and attached file is the patch. thanks -ming ------------------------------------------------------------------------ diff -BburN vm/jitrino/src/jet/cg_ia32.cpp vm-write-barriers/jitrino/src/jet/cg_ia32.cpp --- vm/jitrino/src/jet/cg_ia32.cpp 2006-03-28 22:33:21.000000000 +0800 +++ vm-write-barriers/jitrino/src/jet/cg_ia32.cpp 2006-06-04 11:16:21.000000000 +0800 @@ -2080,6 +2080,12 @@ voper(typeInfo[jt].mov, phi, vstack(1)); } // + if (jt == jobj) { + void *helper = vm_get_rt_support_addr(VM_RT_WRITE_BARRIER_FASTCALL); + gen_mem(MEM_STACK|MEM_VARS|MEM_TO_MEM|MEM_UPDATE); + voper(Mnemonic_MOV, RegName_ECX, rref); + vcall(helper); + } vpop(jt); vpop(jobj); } diff -BburN vm/vmcore/src/jit/jit_runtime_support.cpp vm-write-barriers/vmcore/src/jit/jit_runtime_support.cpp --- vm/vmcore/src/jit/jit_runtime_support.cpp 2006-03-28 22:53:28.000000000 +0800 +++ vm-write-barriers/vmcore/src/jit/jit_runtime_support.cpp 2006-06-04 11:17:36.000000000 +0800 @@ -1657,6 +1657,8 @@ #endifswitch(f) {+ case VM_RT_WRITE_BARRIER_FASTCALL: + return NULL; // Object creation case VM_RT_NEW_RESOLVED_USING_VTABLE_AND_SIZE: return NULL; ------------------------------------------------------------------------ --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
