You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/05/31 00:12:50 UTC
[DRLVM] adding write barriers to Jitrino.JET
All,
I have been looking at DRLVM contained in JIRA Harmony-438. As far as
I can tell, it does not have write barrier support. Write barrier
support is pretty much required for high performance garbage
collectors. In anticipation of using DRLVM with modern GCs like MMTK,
I'd like to add write barrier support.
DRLVM contains a simple JIT called Jitrino.JET in addition to a highly
optimizing JIT. The simple JIT seems to be a better choice for
starting the write barrier work.
Looking at Jitrino.JET sources, it looks like the best place to add
write barriers is in cg_ia32.cpp: Compiler::gen_st() {.......} Does
this seem right?
Also, I have looked for documentation on Jitrino.JET but have not been
able to locate it. It would be nice see some graphic documentation on
how the compiler spill/fills between the stack and registers. And
also how the compiler deals with the live ranges of reference
variables. In specific how root set enumeration works. While not
absolutely essential for hacking in write barriers, it will help a
bunch during the debug stage.
Thanks
--
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] adding write barriers to Jitrino.JET
Posted by Weldon Washburn <we...@gmail.com>.
On 6/2/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> I didn't look at the MMTk source, but IMHO the special translation of
> bytecodes is not nessasary in first stage. If the functionality
> implemented as methods which are handled specially in jikes, in
> interpreter they can be implemented as native methods. Anyway, I do
> not insist on the use of interpreter, just wanted to clarify this
> case.
Good observation. It might be possible to do the following. Write a
special version of the java files sitting in vmmagic that call new,
matching native methods that do the pointer manipulation. No GC can
be allowed in these native methods. Why? Because these routines do
stuff like convert an int containing a raw pointer to an
ObjectReference containing a valid ref ptr. It should be fairly
simple to hold off GC during execution of these natives.
AFIK, all the vmmagic classes implement the Uninterruptible interface.
The interpreter would be modified to poll for GC between intrepreting
each bytecode. If the current method implements the Uninterruptible
interface, polling for GC would be skipped. Admittedly the above
would run slow. Maybe too slow for even development purposes since
every pointer manipulation becomes a native method call. Its tough to
call this one.
>
> As for the patch, you will at least find the places in VM code where
> missing write barriers should be added.
>
> Regards,
> --
> Ivan
>
> 2006/6/2, Weldon Washburn <we...@gmail.com>:
>
> > > 4. The http://issues.apache.org/jira/browse/HARMONY-504 patch has the
> > > corresponding VM and support for WB. In this patch, the interpreter also
> > > supports write barriers. So in theory, one should be able to bring up MMTk
> > > in interpreter mode even before modifying .Jet?
> >
> > After a closer look, I can give a definite "maybe" on this one. In
> > practice it might end up being just as much or more work as bringing
> > up Jitrino.JET because a bunch of MMTK pointer manipulating classes
> > must somehow be translated via javac into bytecode patterns that
> > trigger the interpreter to bend the type safety rules and do stuff
> > like move an int into a ref ptr field. Other approaches would be to
> > modify javac to generate unsafe code (yuk!) We could also use some
> > sort of automated bytecode editor to hack the bytecode stream -- maybe
> > use sed/awk/ruby/perl/forth. The classes in question are located in
> > org.vmmagic.unboxed (I think). Note that once you bring up the
> > interpreter, you still have to bring up the compilers. While still to
> > early to call, using an interpreter approach is not promising.
>
> ---------------------------------------------------------------------
> 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] adding write barriers to Jitrino.JET
Posted by Ivan Volosyuk <iv...@gmail.com>.
I didn't look at the MMTk source, but IMHO the special translation of
bytecodes is not nessasary in first stage. If the functionality
implemented as methods which are handled specially in jikes, in
interpreter they can be implemented as native methods. Anyway, I do
not insist on the use of interpreter, just wanted to clarify this
case.
As for the patch, you will at least find the places in VM code where
missing write barriers should be added.
Regards,
--
Ivan
2006/6/2, Weldon Washburn <we...@gmail.com>:
> > 4. The http://issues.apache.org/jira/browse/HARMONY-504 patch has the
> > corresponding VM and support for WB. In this patch, the interpreter also
> > supports write barriers. So in theory, one should be able to bring up MMTk
> > in interpreter mode even before modifying .Jet?
>
> After a closer look, I can give a definite "maybe" on this one. In
> practice it might end up being just as much or more work as bringing
> up Jitrino.JET because a bunch of MMTK pointer manipulating classes
> must somehow be translated via javac into bytecode patterns that
> trigger the interpreter to bend the type safety rules and do stuff
> like move an int into a ref ptr field. Other approaches would be to
> modify javac to generate unsafe code (yuk!) We could also use some
> sort of automated bytecode editor to hack the bytecode stream -- maybe
> use sed/awk/ruby/perl/forth. The classes in question are located in
> org.vmmagic.unboxed (I think). Note that once you bring up the
> interpreter, you still have to bring up the compilers. While still to
> early to call, using an interpreter approach is not promising.
---------------------------------------------------------------------
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] adding write barriers to Jitrino.JET
Posted by Weldon Washburn <we...@gmail.com>.
On 6/1/06, Rana Dasgupta <rd...@gmail.com> wrote:
> Hi Weldon/Ivan,
> This has been a long thread/dialog. I am going to try and summarize where
> we stand at this stage ( for my own understanding ) and also to invite
> comments on implementation direction and suggestions from knowledgeable VM
> developers on the list. Please fill in if I miss or misstate something :-) I
> have not seen the MMTk implementation.
>
> 1. The DRLVM submission has two jits jitrino.jet and jitrino.opt. The first
> one is a simpler, fast baseline jit. Weldon is proposing to implement the
> barrier functionality here first. The focus is initially not performance,
> but to get MMTk up and running with DRLVM.
Correct.
> 2. For purposes of flexibility, ultimately inlinability, and since MMTk
> needs it, the barrier will be a substituting write barrier. This means that
> .Jet will call the barrier helper( to be defined ) and the barrier
> functionality will do the store + barrier update + whatever special
> functionality needed.
Correct. I will post email shortly on prelim design.
> 3. Read barriers are a future project, though MMTk needs it.
Correct.
> 4. The http://issues.apache.org/jira/browse/HARMONY-504 patch has the
> corresponding VM and support for WB. In this patch, the interpreter also
> supports write barriers. So in theory, one should be able to bring up MMTk
> in interpreter mode even before modifying .Jet?
After a closer look, I can give a definite "maybe" on this one. In
practice it might end up being just as much or more work as bringing
up Jitrino.JET because a bunch of MMTK pointer manipulating classes
must somehow be translated via javac into bytecode patterns that
trigger the interpreter to bend the type safety rules and do stuff
like move an int into a ref ptr field. Other approaches would be to
modify javac to generate unsafe code (yuk!) We could also use some
sort of automated bytecode editor to hack the bytecode stream -- maybe
use sed/awk/ruby/perl/forth. The classes in question are located in
org.vmmagic.unboxed (I think). Note that once you bring up the
interpreter, you still have to bring up the compilers. While still to
early to call, using an interpreter approach is not promising.
> 5. There area a few places in DRLVM code where the substituting barrier
> could be a problem a) an atomic object slot update which does a test and set
> followed by a conventional barrier update. This probably needs its own
> interface entry and will need to be special cased. Ultimately MMTk will need
> to provide some supporting functionality for this b) arraycopy and object
> clone where a lot of updates happen together and then a object level barrier
> is invoked. This code could just be left alone and GC suspended during the
> updates for now.
Correct. In practice, it may not be as big of a deal as it looks.
> 6. Weldon made a late comment that MMTk needs the WB to be in Java. If true,
> this is a major requirement and I did not understand the resolution if any.
Correct. In practice it may not be as bad as it sounds since MMTK by
nature already contains write barriers written in (surprise!) Java.
>
>
>
> Thanks,
> Rana
>
>
---------------------------------------------------------------------
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] adding write barriers to Jitrino.JET
Posted by Rana Dasgupta <rd...@gmail.com>.
Hi Weldon/Ivan,
This has been a long thread/dialog. I am going to try and summarize where
we stand at this stage ( for my own understanding ) and also to invite
comments on implementation direction and suggestions from knowledgeable VM
developers on the list. Please fill in if I miss or misstate something :-) I
have not seen the MMTk implementation.
1. The DRLVM submission has two jits jitrino.jet and jitrino.opt. The first
one is a simpler, fast baseline jit. Weldon is proposing to implement the
barrier functionality here first. The focus is initially not performance,
but to get MMTk up and running with DRLVM.
2. For purposes of flexibility, ultimately inlinability, and since MMTk
needs it, the barrier will be a substituting write barrier. This means that
.Jet will call the barrier helper( to be defined ) and the barrier
functionality will do the store + barrier update + whatever special
functionality needed.
3. Read barriers are a future project, though MMTk needs it.
4. The http://issues.apache.org/jira/browse/HARMONY-504 patch has the
corresponding VM and support for WB. In this patch, the interpreter also
supports write barriers. So in theory, one should be able to bring up MMTk
in interpreter mode even before modifying .Jet?
5. There area a few places in DRLVM code where the substituting barrier
could be a problem a) an atomic object slot update which does a test and set
followed by a conventional barrier update. This probably needs its own
interface entry and will need to be special cased. Ultimately MMTk will need
to provide some supporting functionality for this b) arraycopy and object
clone where a lot of updates happen together and then a object level barrier
is invoked. This code could just be left alone and GC suspended during the
updates for now.
6. Weldon made a late comment that MMTk needs the WB to be in Java. If true,
this is a major requirement and I did not understand the resolution if any.
Thanks,
Rana
On 6/1/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>
> 2006/6/1, Weldon Washburn <we...@gmail.com>:
> > On 6/1/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> > > 2006/6/1, Weldon Washburn <we...@gmail.com>:
> > > > On 5/31/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> > > > > 2006/6/1, Rana Dasgupta <rd...@gmail.com>:
> > > > > We have in DRLVM implementation the atomic exchange of value
> stored in
> > > > > object field. It is required IMO for the j.u.atomics package. It
> > > > > require some additonal function in GC interface to do atomic swap
> of
> > > > > the value with write barrier.
> > > >
> > > > I don't get it. Do you really mean to use atomic swap in the write
> > > > barrier? Why? Where in harmony drlvm do I find this code?
> > >
> > > I have written this thinking from the perspective that we leave only
> > > substituting write barrier mentioned by Rana. Here is the difficult
> > > place to use this approach. For this case in VM currently use
> > > gc_write_barrier(object_with_slot_written_to) just after the
> > > object_write operation.
> > Yes. This is a rough spot. MMTK really wants a substituting write
> > barrier that is written entirely in Java. At least initially, I think
>
> Oops. This complicates things much. I have realized that we can have
> more problems. I didn't looked at MMTk yet so I didn't understand this
> requirement. Now...
>
> Invocation of Java code at write barrier means that it should be
> GC-safe point. As the writting to slot operates with direct pointers
> this code is not GC-safe. So existing VM and interpreter write
> barriers are not ready for MMTk :(
>
> > we should call the existing native code support for clone and
> > arraycopy. Else we end up rewritting the entire jvm in java. For
> > initial bring up, it should be OK to simply disallow GC during clone
> > and arraycopy's memcpy() operation.
>
> Note: this could be not enough depending on the algorithms used by
> MMTk, but might work for some of them.
>
> > >
> > > >
> > >> > This is really confusing. I am looking at
> > > > optimize_ia32.cpp:gen_native_arraycopy_fastpath() and
> > > > object_generic.cpp:object_clone() from JIRA Harmony-438. Can you
> tell
> > > > me which lines of code contain the "special write barrier"?
> > >
> > > I was talking about vm_arrays.cpp:array_copy() and
> > > object_generic.cpp:object_clone()
> > > The same code used here, instead of substituting write barrier we
> > > write all the object data and (avoiding GC) call
> > > write_barrier(object_with_slot_written_to).
> >
> > Agreed. We are saying the same thing.
> >
> > >
> > > >
> > > > As far as I understand, I should use Harmony-438 as the base to add
> > > > the write barrier code. Is this correct?
> > >
> > > As I mentioned before, you can use patch from
> > > http://issues.apache.org/jira/browse/HARMONY-504. It contains changes
> > > in VM and interpreter code adding missing write barriers there.
> >
> > I looked at 504. All of this is starting to make sense.
> >
> > >
> > > You can try to bring MMTk to work using interpreter mode. I have
> > > validated the correctness of write barriers and they should work ok.
> >
> > I did not realize this. What did you test interpreter write barriers
> with?
>
> I have created per-slot mirror of heap. The write barrier did the
> writting of value to the heap object's slot and the mirrored object's
> slot too. I have used stop-the-world GC. Before each GC there was a
> pass comparing all slots with their mirrors. After the GC mirror was
> synchronized with the heap. Thus, I have found all missing write
> barriers.
>
> > > If you are going to make jitrino.jet changes, it is worth to
> > > find/implement a tool which will validate the correctness of this new
> > > write barriers implementation, otherwise you may end up spending great
> > > amount of time investigating random crashes.
> >
> > Good point. Please remind me when I get to that stage of development
> > to ask harmony-dev if anyone has a tool for validating write barrier
> > correctness. I will also look at MMTK sources to see if any such
> > facility exists.
>
> --
> Ivan
> 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] adding write barriers to Jitrino.JET
Posted by Ivan Volosyuk <iv...@gmail.com>.
2006/6/1, Weldon Washburn <we...@gmail.com>:
> On 6/1/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> > 2006/6/1, Weldon Washburn <we...@gmail.com>:
> > > On 5/31/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> > > > 2006/6/1, Rana Dasgupta <rd...@gmail.com>:
> > > > We have in DRLVM implementation the atomic exchange of value stored in
> > > > object field. It is required IMO for the j.u.atomics package. It
> > > > require some additonal function in GC interface to do atomic swap of
> > > > the value with write barrier.
> > >
> > > I don't get it. Do you really mean to use atomic swap in the write
> > > barrier? Why? Where in harmony drlvm do I find this code?
> >
> > I have written this thinking from the perspective that we leave only
> > substituting write barrier mentioned by Rana. Here is the difficult
> > place to use this approach. For this case in VM currently use
> > gc_write_barrier(object_with_slot_written_to) just after the
> > object_write operation.
> Yes. This is a rough spot. MMTK really wants a substituting write
> barrier that is written entirely in Java. At least initially, I think
Oops. This complicates things much. I have realized that we can have
more problems. I didn't looked at MMTk yet so I didn't understand this
requirement. Now...
Invocation of Java code at write barrier means that it should be
GC-safe point. As the writting to slot operates with direct pointers
this code is not GC-safe. So existing VM and interpreter write
barriers are not ready for MMTk :(
> we should call the existing native code support for clone and
> arraycopy. Else we end up rewritting the entire jvm in java. For
> initial bring up, it should be OK to simply disallow GC during clone
> and arraycopy's memcpy() operation.
Note: this could be not enough depending on the algorithms used by
MMTk, but might work for some of them.
> >
> > >
> >> > This is really confusing. I am looking at
> > > optimize_ia32.cpp:gen_native_arraycopy_fastpath() and
> > > object_generic.cpp:object_clone() from JIRA Harmony-438. Can you tell
> > > me which lines of code contain the "special write barrier"?
> >
> > I was talking about vm_arrays.cpp:array_copy() and
> > object_generic.cpp:object_clone()
> > The same code used here, instead of substituting write barrier we
> > write all the object data and (avoiding GC) call
> > write_barrier(object_with_slot_written_to).
>
> Agreed. We are saying the same thing.
>
> >
> > >
> > > As far as I understand, I should use Harmony-438 as the base to add
> > > the write barrier code. Is this correct?
> >
> > As I mentioned before, you can use patch from
> > http://issues.apache.org/jira/browse/HARMONY-504. It contains changes
> > in VM and interpreter code adding missing write barriers there.
>
> I looked at 504. All of this is starting to make sense.
>
> >
> > You can try to bring MMTk to work using interpreter mode. I have
> > validated the correctness of write barriers and they should work ok.
>
> I did not realize this. What did you test interpreter write barriers with?
I have created per-slot mirror of heap. The write barrier did the
writting of value to the heap object's slot and the mirrored object's
slot too. I have used stop-the-world GC. Before each GC there was a
pass comparing all slots with their mirrors. After the GC mirror was
synchronized with the heap. Thus, I have found all missing write
barriers.
> > If you are going to make jitrino.jet changes, it is worth to
> > find/implement a tool which will validate the correctness of this new
> > write barriers implementation, otherwise you may end up spending great
> > amount of time investigating random crashes.
>
> Good point. Please remind me when I get to that stage of development
> to ask harmony-dev if anyone has a tool for validating write barrier
> correctness. I will also look at MMTK sources to see if any such
> facility exists.
--
Ivan
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] adding write barriers to Jitrino.JET
Posted by Weldon Washburn <we...@gmail.com>.
On 6/1/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> 2006/6/1, Weldon Washburn <we...@gmail.com>:
> > On 5/31/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> > > 2006/6/1, Rana Dasgupta <rd...@gmail.com>:
> > > We have in DRLVM implementation the atomic exchange of value stored in
> > > object field. It is required IMO for the j.u.atomics package. It
> > > require some additonal function in GC interface to do atomic swap of
> > > the value with write barrier.
> >
> > I don't get it. Do you really mean to use atomic swap in the write
> > barrier? Why? Where in harmony drlvm do I find this code?
>
> I have written this thinking from the perspective that we leave only
> substituting write barrier mentioned by Rana. Here is the difficult
> place to use this approach. For this case in VM currently use
> gc_write_barrier(object_with_slot_written_to) just after the
> object_write operation.
Yes. This is a rough spot. MMTK really wants a substituting write
barrier that is written entirely in Java. At least initially, I think
we should call the existing native code support for clone and
arraycopy. Else we end up rewritting the entire jvm in java. For
initial bring up, it should be OK to simply disallow GC during clone
and arraycopy's memcpy() operation.
>
> >
>> > This is really confusing. I am looking at
> > optimize_ia32.cpp:gen_native_arraycopy_fastpath() and
> > object_generic.cpp:object_clone() from JIRA Harmony-438. Can you tell
> > me which lines of code contain the "special write barrier"?
>
> I was talking about vm_arrays.cpp:array_copy() and
> object_generic.cpp:object_clone()
> The same code used here, instead of substituting write barrier we
> write all the object data and (avoiding GC) call
> write_barrier(object_with_slot_written_to).
Agreed. We are saying the same thing.
>
> >
> > As far as I understand, I should use Harmony-438 as the base to add
> > the write barrier code. Is this correct?
>
> As I mentioned before, you can use patch from
> http://issues.apache.org/jira/browse/HARMONY-504. It contains changes
> in VM and interpreter code adding missing write barriers there.
I looked at 504. All of this is starting to make sense.
>
> You can try to bring MMTk to work using interpreter mode. I have
> validated the correctness of write barriers and they should work ok.
I did not realize this. What did you test interpreter write barriers with?
>
> If you are going to make jitrino.jet changes, it is worth to
> find/implement a tool which will validate the correctness of this new
> write barriers implementation, otherwise you may end up spending great
> amount of time investigating random crashes.
Good point. Please remind me when I get to that stage of development
to ask harmony-dev if anyone has a tool for validating write barrier
correctness. I will also look at MMTK sources to see if any such
facility exists.
> --
> Ivan
> 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
>
>
--
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] adding write barriers to Jitrino.JET
Posted by Ivan Volosyuk <iv...@gmail.com>.
2006/6/1, Weldon Washburn <we...@gmail.com>:
> On 5/31/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> > 2006/6/1, Rana Dasgupta <rd...@gmail.com>:
> > >
> > > It may be worth considering if we want JET to just call the barrier
> > > functionality( with from/to/and slot locations )and the barrier helper
> > > actually do everything ... including generating the store. May be
> > > unconventional, but more modular.
> >
> > Actually, this is the best way to do that. Thus we allow much
> > flexibility for the implementation of write barriers. I have found a
> > few exceptions from this rule in DRLVM VM code. It is the
> > implementation of atomic exchange of object field value, arraycopy and
> > object_clone. We should think about this to.
> hmm.... I suspect the fundamental problem is that from the GC's
> perspective if a write to a heap location that contains a reference
> has occurred, the GC must also see the write barrier. Interestingly
> it is OK if the GC sees a write barrier without the corresponding
> field changing value. In this case, the GC will scan a field that
> simply has not changed. A small waste of time but still correct.
>
> From what I recall, there are two ways to solve the atomic
> (write_object, write_barrier) tuple problem. Either use an
> instruction like a DCAS (double compare and swap) or guarantee that a
> GC can not happen between the move to object field and write barrier
> code. The last time I looked, ia32 does not have DCAS instruction.
> In addition, each write of a reference to the Java heap would mean the
> HW issues an atomic operation. This could get expensive. Thus its not
> worthwhile discussing this approach further. An approach that I used
> in ORP was to guarantee that a thread can not be suspended for a GC
> between the write_object and write_barrier pair. The details are
> longer than this email will allow.
Agree. Avoiding GC between write_object and write_barrier is enough.
>
> > Let me give you a few
> > details.
> >
> > We have in DRLVM implementation the atomic exchange of value stored in
> > object field. It is required IMO for the j.u.atomics package. It
> > require some additonal function in GC interface to do atomic swap of
> > the value with write barrier.
>
> I don't get it. Do you really mean to use atomic swap in the write
> barrier? Why? Where in harmony drlvm do I find this code?
I have written this thinking from the perspective that we leave only
substituting write barrier mentioned by Rana. Here is the difficult
place to use this approach. For this case in VM currently use
gc_write_barrier(object_with_slot_written_to) just after the
object_write operation.
>
> >
> > Object clone and System.arraycopy write/modify whole object with
> > number of references in it. For the performance its currently use
> > special write barrier function which simply gives the object reference
> > saying: the whole object is changed - do something.
> >We can leave the
> > variant of write barrier or just remove it and change these functions
> > respectivly.
>
> This is really confusing. I am looking at
> optimize_ia32.cpp:gen_native_arraycopy_fastpath() and
> object_generic.cpp:object_clone() from JIRA Harmony-438. Can you tell
> me which lines of code contain the "special write barrier"?
I was talking about vm_arrays.cpp:array_copy() and
object_generic.cpp:object_clone()
The same code used here, instead of substituting write barrier we
write all the object data and (avoiding GC) call
write_barrier(object_with_slot_written_to).
>
> As far as I understand, I should use Harmony-438 as the base to add
> the write barrier code. Is this correct?
As I mentioned before, you can use patch from
http://issues.apache.org/jira/browse/HARMONY-504. It contains changes
in VM and interpreter code adding missing write barriers there.
You can try to bring MMTk to work using interpreter mode. I have
validated the correctness of write barriers and they should work ok.
If you are going to make jitrino.jet changes, it is worth to
find/implement a tool which will validate the correctness of this new
write barriers implementation, otherwise you may end up spending great
amount of time investigating random crashes.
--
Ivan
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] adding write barriers to Jitrino.JET
Posted by Weldon Washburn <we...@gmail.com>.
On 5/31/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> 2006/6/1, Rana Dasgupta <rd...@gmail.com>:
> >
> > It may be worth considering if we want JET to just call the barrier
> > functionality( with from/to/and slot locations )and the barrier helper
> > actually do everything ... including generating the store. May be
> > unconventional, but more modular.
>
> Actually, this is the best way to do that. Thus we allow much
> flexibility for the implementation of write barriers. I have found a
> few exceptions from this rule in DRLVM VM code. It is the
> implementation of atomic exchange of object field value, arraycopy and
> object_clone. We should think about this to.
hmm.... I suspect the fundamental problem is that from the GC's
perspective if a write to a heap location that contains a reference
has occurred, the GC must also see the write barrier. Interestingly
it is OK if the GC sees a write barrier without the corresponding
field changing value. In this case, the GC will scan a field that
simply has not changed. A small waste of time but still correct.
>From what I recall, there are two ways to solve the atomic
(write_object, write_barrier) tuple problem. Either use an
instruction like a DCAS (double compare and swap) or guarantee that a
GC can not happen between the move to object field and write barrier
code. The last time I looked, ia32 does not have DCAS instruction.
In addition, each write of a reference to the Java heap would mean the
HW issues an atomic operation. This could get expensive. Thus its not
worthwhile discussing this approach further. An approach that I used
in ORP was to guarantee that a thread can not be suspended for a GC
between the write_object and write_barrier pair. The details are
longer than this email will allow.
> Let me give you a few
> details.
>
> We have in DRLVM implementation the atomic exchange of value stored in
> object field. It is required IMO for the j.u.atomics package. It
> require some additonal function in GC interface to do atomic swap of
> the value with write barrier.
I don't get it. Do you really mean to use atomic swap in the write
barrier? Why? Where in harmony drlvm do I find this code?
>
> Object clone and System.arraycopy write/modify whole object with
> number of references in it. For the performance its currently use
> special write barrier function which simply gives the object reference
> saying: the whole object is changed - do something.
>We can leave the
> variant of write barrier or just remove it and change these functions
> respectivly.
This is really confusing. I am looking at
optimize_ia32.cpp:gen_native_arraycopy_fastpath() and
object_generic.cpp:object_clone() from JIRA Harmony-438. Can you tell
me which lines of code contain the "special write barrier"?
As far as I understand, I should use Harmony-438 as the base to add
the write barrier code. Is this correct?
>
> Best regards,
> --
> Ivan
> 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
>
>
--
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] adding write barriers to Jitrino.JET
Posted by Ivan Volosyuk <iv...@gmail.com>.
2006/6/1, Rana Dasgupta <rd...@gmail.com>:
> > >> How will it affect VM or GC ? The WBs will also require support from
> > both VM
> > >> and GC. Do you have ideas on VM/GC interface for this?
> > > >Also what will be usage and testing scenarios in the nearest future?
> >
> > >The VM<>GC interfaces is already exists in DRLVM. The only interface
> > >is missing: JIT->VM helper.
>
>
> Not sure that I understood what you said here...are you saying that the
> VM_GC interface has (stubbed out) barriers related entries( eg.,
> gc_requires_barrier()/gc_write_barrier()), but the JIT->VM Helper runtime
> support interface does not have the necessary barrier helper entries in this
> code version?
Yes, exactly.
>
> It may be worth considering if we want JET to just call the barrier
> functionality( with from/to/and slot locations )and the barrier helper
> actually do everything ... including generating the store. May be
> unconventional, but more modular.
Actually, this is the best way to do that. Thus we allow much
flexibility for the implementation of write barriers. I have found a
few exceptions from this rule in DRLVM VM code. It is the
implementation of atomic exchange of object field value, arraycopy and
object_clone. We should think about this to. Let me give you a few
details.
We have in DRLVM implementation the atomic exchange of value stored in
object field. It is required IMO for the j.u.atomics package. It
require some additonal function in GC interface to do atomic swap of
the value with write barrier.
Object clone and System.arraycopy write/modify whole object with
number of references in it. For the performance its currently use
special write barrier function which simply gives the object reference
saying: the whole object is changed - do something. We can leave the
variant of write barrier or just remove it and change these functions
respectivly.
Best regards,
--
Ivan
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] adding write barriers to Jitrino.JET
Posted by Weldon Washburn <we...@gmail.com>.
On 5/31/06, Rana Dasgupta <rd...@gmail.com> wrote:
> On 5/31/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> >
> > 2006/5/31, Mikhail Fursov <mi...@gmail.com>:
> > >> No, this method is used to store operand stack item to local
> > variable. If
> > >> you're interested in writing to fields then Compiler::gen_field_op is
> > the
> > >> right place. We can generate a call to VM or GC helper in this method.
> > To
> > >> create a call to any VM helper (which may throw Exception or force GC)
> > you
> > >> should use Compiler::gen_call_vm() method.
> >
> > >FYI: Write barrier GC implementation doesn't throw exceptions or
> > >starts garbage collection. The whole idea of write barriers is to make
> > >them as lightweight as possible.
I don't care about how lightweight the write barrier at this stage of
development. See below.
>
>
> gen_call_vm() is more heavyweight( as Ivan explains above ), but that's
> why the higher level goals of this feature development would be good to
> know. Prototyping in .Jet cannot really have a performance focus.
Correct. Performance is a non-goal for the initial bring up on .JET.
My thinking is that once .JET/MMTK is "bullet proof", we worry about
bringing up the optimizing JIT. Meanwhile the bullet proof .JET is
not modified so that we can use it to chase write barrier bugs in the
optimizing compiler. Once the optimizing compiler is stable and the
lightweight WB's are inlined, the third stage is to go back and
performance profile .JET. Use this perf info as a guide to fix .JET
write barrier performance problems.
> Weldon, would it be right to call this a proof of concept, to be later
> redone in the .OPT jit when necessary?
Instead of "proof of concept", I would use the term, "initial bring up".
>
> >> It seems not to be a problem to implement WB support in Jitrino.JET,
> > let's
> > >> discuss requirements and design.
> > >> How will it affect VM or GC ? The WBs will also require support from
> > both VM
> > >> and GC. Do you have ideas on VM/GC interface for this?
I am reading the MMTK source code now. I should have comments on
mix/matching MMTK interface and OPEN and DRLVM GC interface(s) soon.
> > > >Also what will be usage and testing scenarios in the nearest future?
Probably the best option is to test write barriers using MMTK. The
existing GC in DRLVM (gcv4) is probably going to be too hard to work
with. Also, writing a GC from scratch is a possibility but I would
rather go with an existing, known to work GC (mmtk or some other
battle tested 3rd party open source GC).
> >
> > >The VM<>GC interfaces is already exists in DRLVM. The only interface
> > >is missing: JIT->VM helper.
Yes. I am aware of this interface. I need to look at harmony-438
sources to see if it has changed since I last worked on this interface
back when I posted ORP to sourceforge in 2000. If memory serves me
correct, ORP contains GCV3 which is an incremental moving collector.
And write barriers were working just fine.
>
>
> Not sure that I understood what you said here...are you saying that the
> VM_GC interface has (stubbed out) barriers related entries( eg.,
> gc_requires_barrier()/gc_write_barrier()), but the JIT->VM Helper runtime
> support interface does not have the necessary barrier helper entries in this
> code version?
I don't want to inline write barrier code in Jitrino.JET during this
startup stage. It needs to call a runtime helper function. If the
function is missing, it needs to be added to the runtime helper table.
>
> It may be worth considering if we want JET to just call the barrier
> functionality( with from/to/and slot locations )and the barrier helper
> actually do everything ... including generating the store. May be
> unconventional, but more modular.
I really want to take the lazy way out. If it is easier to leave the
store code as it is, then that's what will be done. If it is easier
to clump the WB code and the java store code together, then do that
instead.
>
> Thanks,
> Rana
>
>
>
>
>
>
>
> --
> > Ivan
> >
> > ---------------------------------------------------------------------
> > 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] adding write barriers to Jitrino.JET
Posted by Rana Dasgupta <rd...@gmail.com>.
On 5/31/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>
> 2006/5/31, Mikhail Fursov <mi...@gmail.com>:
> >> No, this method is used to store operand stack item to local
> variable. If
> >> you're interested in writing to fields then Compiler::gen_field_op is
> the
> >> right place. We can generate a call to VM or GC helper in this method.
> To
> >> create a call to any VM helper (which may throw Exception or force GC)
> you
> >> should use Compiler::gen_call_vm() method.
>
> >FYI: Write barrier GC implementation doesn't throw exceptions or
> >starts garbage collection. The whole idea of write barriers is to make
> >them as lightweight as possible.
gen_call_vm() is more heavyweight( as Ivan explains above ), but that's
why the higher level goals of this feature development would be good to
know. Prototyping in .Jet cannot really have a performance focus.
Weldon, would it be right to call this a proof of concept, to be later
redone in the .OPT jit when necessary?
>> It seems not to be a problem to implement WB support in Jitrino.JET,
> let's
> >> discuss requirements and design.
> >> How will it affect VM or GC ? The WBs will also require support from
> both VM
> >> and GC. Do you have ideas on VM/GC interface for this?
> > >Also what will be usage and testing scenarios in the nearest future?
>
> >The VM<>GC interfaces is already exists in DRLVM. The only interface
> >is missing: JIT->VM helper.
Not sure that I understood what you said here...are you saying that the
VM_GC interface has (stubbed out) barriers related entries( eg.,
gc_requires_barrier()/gc_write_barrier()), but the JIT->VM Helper runtime
support interface does not have the necessary barrier helper entries in this
code version?
It may be worth considering if we want JET to just call the barrier
functionality( with from/to/and slot locations )and the barrier helper
actually do everything ... including generating the store. May be
unconventional, but more modular.
Thanks,
Rana
--
> Ivan
>
> ---------------------------------------------------------------------
> 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] adding write barriers to Jitrino.JET
Posted by Ivan Volosyuk <iv...@gmail.com>.
2006/5/31, Mikhail Fursov <mi...@gmail.com>:
> No, this method is used to store operand stack item to local variable. If
> you're interested in writing to fields then Compiler::gen_field_op is the
> right place. We can generate a call to VM or GC helper in this method. To
> create a call to any VM helper (which may throw Exception or force GC) you
> should use Compiler::gen_call_vm() method.
FYI: Write barrier GC implementation doesn't throw exceptions or
starts garbage collection. The whole idea of write barriers is to make
them as lightweight as possible.
> It seems not to be a problem to implement WB support in Jitrino.JET, let's
> discuss requirements and design.
> How will it affect VM or GC ? The WBs will also require support from both VM
> and GC. Do you have ideas on VM/GC interface for this?
> Also what will be usage and testing scenarios in the nearest future?
The VM<>GC interfaces is already exists in DRLVM. The only interface
is missing: JIT->VM helper.
--
Ivan
---------------------------------------------------------------------
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] adding write barriers to Jitrino.JET
Posted by Mikhail Fursov <mi...@gmail.com>.
On 5/31/06, Weldon Washburn <we...@gmail.com> wrote:
>
> DRLVM contains a simple JIT called Jitrino.JET in addition to a highly
> optimizing JIT. The simple JIT seems to be a better choice for
> starting the write barrier work.
>
> Looking at Jitrino.JET sources, it looks like the best place to add
> write barriers is in cg_ia32.cpp: Compiler::gen_st() {.......} Does
> this seem right?
No, this method is used to store operand stack item to local variable. If
you're interested in writing to fields then Compiler::gen_field_op is the
right place. We can generate a call to VM or GC helper in this method. To
create a call to any VM helper (which may throw Exception or force GC) you
should use Compiler::gen_call_vm() method.
Also, I have looked for documentation on Jitrino.JET but have not been
> able to locate it.
The brief overview of Jitrino.JET features is in DRL VM Developers Guide.
For more detailed information you can generate Doxygen documentation. To
generate Doxygen documentation for Jitrino.JET browse to vm/jitrino/src/jet
folder and run 'doxygen -g', 'doxygen Doxyfile' commands.
It would be nice see some graphic documentation on
> how the compiler spill/fills between the stack and registers. And
> also how the compiler deals with the live ranges of reference
> variables.
Jitrino.JET is designed to be a pretty simple baseline compiler. It does
not perform optimizations or data/control flow analysis. Operands do not
live across call sites on registers. i.e. Jitrino.JET spills into memory
every operand before a call. The live range of operand is exactly the same
as in bytecode, so even if object reference will never be used again, but
occupies a local variable or stack slot in Java bytecode, Jitrino.JET will
report it to GC during enumeration.
In specific how root set enumeration works. While not
> absolutely essential for hacking in write barriers, it will help a
> bunch during the debug stage.
Root set enumeration works as follows: Jitrino.JET emulates Java
stack/locals and has reserved areas in stack frame (see
Jitrino::Jet::StackFrame class) to map bytecode locals and stack slots. For
every GC enumeration point JET maintains two masks: "GC map for locals" and
"GC map for stack" which define which variables and which stack slots must
be reported to GC. Both masks are saved to StackFrame in runtime right
before GCenumeration point, but calculated separately. Locals mask is always
calculated in
runtime: every store operation changes a bit in mask. Stack operands mask is
calculated during compilation and
is a constant for every GC enumeration point.
It seems not to be a problem to implement WB support in Jitrino.JET, let's
discuss requirements and design.
How will it affect VM or GC ? The WBs will also require support from both VM
and GC. Do you have ideas on VM/GC interface for this?
Also what will be usage and testing scenarios in the nearest future?
--
Mikhail Fursov
Intel Middleware Products Division