On 5/31/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
2006/6/1, Rana Dasgupta <[EMAIL PROTECTED]>:
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Weldon Washburn
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]
