On the 0x1F1 day of Apache Harmony Xiao-Feng Li wrote: > Thanks. Yes, this is supposed to be review by JIT person. On the other > hand, if JIT person has better solution, GCv5 would like to use. > Anyway we hope write barrier is to be functioning in the DRLVM soon.
As a JIT-oriented guy, I looked through the patch. Looks good. The write barrier does NOT push an M2N frame before invoking gc_heap_slot_write_ref(), but it's OK since there will be no stack unwinding from here. I am curious about the switch VM_Global_State::loader_env->use_lil_stubs. Does everything work in both true and false? What do we need this switch for? Doesn't it induce unnecessary complication/duplication? > On 9/27/06, Weldon Washburn <[EMAIL PROTECTED]> wrote: > > It would probably be best if a JIT person committed this patch. Maybe > > Stephan Mishura? > > > > If its not committed soon, bug me and I will do it. > > > > > > On 9/26/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > > > > > > Hi, the patch attached in JIRA 1580 (submitted by YuNan) is a write > > > barrier implementation for JET that GCv5 is going to use (it doesn't > > > impact anything else). It would be great if some commiter can help to > > > review and commit it. Thanks. -xiaofeng > > > > > > http://issues.apache.org/jira/browse/HARMONY-1580?page=all > > > > > > The patch is against revision revision 442796. > > > > > > Repeat the desciption of the patch: > > > "Attached patch is an implementation of write barrier for JET compiler > > > of DRLVM. The patch lets JET to call "gc_requires_barriers()" of GC to > > > determine if it needs to insert the write barrier code into the jitted > > > code, so it doesn't impact current DRLVM/GC at all. It calls > > > gc_heap_slot_write_ref( ) of GC module, which takes three parameters. > > > The signature is "void gc_heap_slot_write_ref (Managed_Object_Handle > > > p_obj_holding_ref,Managed_Object_Handle *p_slot, Managed_Object_Handle > > > p_target)". > > > > > > The patch is based on revision 442796. We hope it can be committed to > > > Harmony soon because GCv5 will be depending on it. We don't use > > > existing getaddress__gc_write_barrier_fastcall () in DRLVM because it > > > only remembers object rather than the slot, and the name is not > > > descriptive. But we may use it later. Thanks." > > > > > > --------------------------------------------------------------------- > > > Terms of use : http://incubator.apache.org/harmony/mailing.html > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > 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] > > -- Egor Pasko, Intel Managed Runtime Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
