harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
Date Wed, 27 Sep 2006 10:20:36 GMT
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 <weldonwjw@gmail.com> 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 <xiaofeng.li@gmail.com> 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: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Weldon Washburn
> > 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
> 
> 

-- 
Egor Pasko, Intel Managed Runtime 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


Mime
View raw message