harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weldon Washburn" <weldon...@gmail.com>
Subject Re: [DRLVM] adding write barriers to Jitrino.JET
Date Thu, 01 Jun 2006 04:00:28 GMT
On 5/31/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
> 2006/6/1, Rana Dasgupta <rdasgupt@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


Mime
View raw message