You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Xiao-Feng Li <xi...@gmail.com> on 2006/09/26 11:17:15 UTC
[DRLVM] (JIRA 1580) write barrier implementation for JET
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
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 9/28/06, Gregory Shimansky <gs...@gmail.com> wrote:
> 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.
No, stack should never be examined in write barrier. That's completely
contridicting the purpose of write barrier.
Thanks,
xiaofeng
---------------------------------------------------------------------
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
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
Posted by Gregory Shimansky <gs...@gmail.com>.
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 <we...@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 <xi...@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."
--
Gregory Shimansky, 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
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
Posted by Weldon Washburn <we...@gmail.com>.
On 9/27/06, Xiao-Feng Li <xi...@gmail.com> wrote:
>
> Thanks to Egor and Gregory's responses to the JET write barrier patch.
> Those help. I was away from JIT development for a while. :-)
>
> Since the patch is small, if needed, please feel free to modify it as
> a JIRA update, or a committer to merge it then we submit new patch
> later. Basically the write barrier should be as small (quick) as
> possible and involves no additional VM runtime operations. A view to
> write barrier can be that, it is only an extended bytecode of the
> orignal reference store one. That means, we can implement it in anyway
> appropriate as long as the semantics of the reference store is kept,
> either in JIT IR, in LIL,
Please no LiL. We need to replace LiL code with either Java/vmmagic, jit
intrinsic or emitter based asm code. Even JIT IR would be preferable to
LiL.
in asm or as a function call. Performance
> and flexibility are the main goals. The performance is easy to
> understand, the flexibility refers to that a GC developer probably can
> conveniently change the write barrier implementation.
>
> As I know, a volunteer (Mikhail Fursov?) is writing helper inlining
> for DRLVM. Hopefully that will be the ultimate solution for write
> barrier implementation. Before that is ready, an intermediate solution
> would be acceptable.
>
> Thanks,
> xiaofeng
>
> > On 27 Sep 2006 17:20:36 +0700, Egor Pasko <eg...@gmail.com> wrote:
> > 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?
>
> ---------------------------------------------------------------------
> 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
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
Posted by Xiao-Feng Li <xi...@gmail.com>.
Thanks to Egor and Gregory's responses to the JET write barrier patch.
Those help. I was away from JIT development for a while. :-)
Since the patch is small, if needed, please feel free to modify it as
a JIRA update, or a committer to merge it then we submit new patch
later. Basically the write barrier should be as small (quick) as
possible and involves no additional VM runtime operations. A view to
write barrier can be that, it is only an extended bytecode of the
orignal reference store one. That means, we can implement it in anyway
appropriate as long as the semantics of the reference store is kept,
either in JIT IR, in LIL, in asm or as a function call. Performance
and flexibility are the main goals. The performance is easy to
understand, the flexibility refers to that a GC developer probably can
conveniently change the write barrier implementation.
As I know, a volunteer (Mikhail Fursov?) is writing helper inlining
for DRLVM. Hopefully that will be the ultimate solution for write
barrier implementation. Before that is ready, an intermediate solution
would be acceptable.
Thanks,
xiaofeng
> On 27 Sep 2006 17:20:36 +0700, Egor Pasko <eg...@gmail.com> wrote:
> 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?
---------------------------------------------------------------------
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
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
Posted by Xiao-Feng Li <xi...@gmail.com>.
On 27 Sep 2006 17:20:36 +0700, Egor Pasko <eg...@gmail.com> wrote:
> 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?
The LIL stub has been tested. It is there as a place holder for future
write barrier optimizations.
Thanks,
xiaofeng
---------------------------------------------------------------------
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
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
Posted by Egor Pasko <eg...@gmail.com>.
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 <we...@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 <xi...@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
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
Posted by Xiao-Feng Li <xi...@gmail.com>.
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.
Thanks,
xiaofeng
On 9/27/06, Weldon Washburn <we...@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 <xi...@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
Re: [DRLVM] (JIRA 1580) write barrier implementation for JET
Posted by Weldon Washburn <we...@gmail.com>.
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 <xi...@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