On Wednesday 27 September 2006 14:20 Egor Pasko wrote: > 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 want to make sure that there are going to be no JVMTI events sent inside of gc_heap_slot_write_ref. Otherwise M2N frame is necessary to allow stack iterator to work in case a JVMTI agent calls something like GetStackTrace. Also can a hardware exception occur as a result of this helper call? Just a note. Patch uses tabs and DOS EOLs. Can we use spaces and unix line endings instead? > 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." -- Gregory Shimansky, 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]
