Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of a.y.chernyshev@gmail.com
 designates 66.249.92.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=FNQfFU2jvCmod0q3cD0VbWfQ6xV/uH+aj3sG9GOsZ9iTHbJzoERJpGSCQ3h5Iu/HmC2FXhE9xnILrANswRMv1kpFnnR2+wvrmghrlo9Tmmf26XBz6D5ChNhRPntQK3X5htXheR0I3jFVsAvLa6daAyL6A5s9rPi5SKJmgmajTB4=
Message-ID: <6928c5160606210752k6940abfenbc42b0df0266a3f1@mail.gmail.com>
Date: Wed, 21 Jun 2006 18:52:28 +0400
From: "Andrey Chernyshev" <a.y.chernyshev@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
In-Reply-To: <000001c69287$6337f650$0a01a8c0@LITTLEGUY>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <187bb05d0606160452x5111b035jf448f387fb5f0a86@mail.gmail.com>
	 <000001c69287$6337f650$0a01a8c0@LITTLEGUY>

On 6/18/06, Nathan Beyer <nbeyer@kc.rr.com> wrote:
> Thanks. How does the Atomics class work in regards to volatile reads of
> elements of an array? Here's the class I'm looking at implementing with the
> Atomics API [1]. The CAS operations are trivial. It's the 'get' and 'set'
> methods that I'm trying to figure out.

Hi Nathan,

Atomics in drlvm has a function MemoryReadWriteBarrier() defined in
atomics.h (see http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/atomics.h)
which can be utilized for implementing volatile reads and writes for
AtomicIntegerArray.  Some work, however, will still be needed for
atomics.cpp to add volatile set() and get() implementations accessible
through JNI interface.

Another approach to implement AtomicArray.get and set could be via CAS
operation. For example, for set() method, you simply can do something
like:
    int orig = arr[i]; // guess original master value
    compareAndSet(i, orig, newValue); // set new value; if the
original value is unexpected, it would just mean that someone else has
changed it concurrently which is OK for this case and we just do
nothing;

For get() method, algorithm could be like:
    int orig = arr[i];
    compareAndSet(i, 0, 0); // do CAS with whatever value, this
ensures cache is flushed;
    return arr[i]; // return the master value

In terms of the speed, it must be almost same as doing mfense, at
least on IA32 (mfense is probably 20-30% faster).

Thank you,
Andrey Chernyshev
Intel Middleware Products Division

>
> -Nathan
>
> [1]
> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concu
> rrent/atomic/AtomicIntegerArray.java?rev=1.19&only_with_tag=JSR166_PFD&conte
> nt-type=text/vnd.viewcvs-markup
>
> > -----Original Message-----
> > From: Artem Aliev [mailto:artem.aliev@gmail.com]
> > Sent: Friday, June 16, 2006 6:52 AM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
> >
> > Nathan,
> >
> > > VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a
> > > VM-specific API for atomic gets and sets. This API will need to be
> > defined
> > > and then implemented by the various VMs. Many of the lock APIs also make
> > use
> > > of this API.
> >
> > I have done some experiments with concurrent in DRLVM. So there are
> > two kernel classes in the DRLVM that, probably, provide full set of VM
> > dependent
> > functionality required by util.concurrent. Both have special VM support.
> >
> > vm/vmcore/src/kernel_classes/javasrc/java/util/concurrent/locks/LockSuppor
> > t.java
> > -- park/unpark methods
> >
> > The special queue could be used in case you need to implement it in VM
> > independent way.
> >
> > vm/vmcore/src/kernel_classes/javasrc/org/apache/harmony/util/concurrent/At
> > omics.java
> >  -- CAS operations on references, ints, longs etc.
> >
> > The methods are aware of internal object layout and reference format.
> > VM independent implementation could be done base on java monitors, but
> > it kills the idea of the util.concurrent.
> >
> > Thanks
> > Artem Aliev
> > Intel Middleware Product Division
> >
> >
> >
> > On 6/14/06, Nathan Beyer <nbeyer@kc.rr.com> wrote:
> > > I stubbed out the method in luni-kernel (as well as two other methods
> > that
> > > were missing). I looked at DRLVM and it already has nanoTime
> > implementation,
> > > but it's not using the method you mentioned. I took a peek at the
> > > JCHEVM/classlibadaptar, but I couldn't quite discern the various
> > artifacts.
> > >
> > > -Nathan
> > >
> > > > -----Original Message-----
> > > > From: Tim Ellison [mailto:t.p.ellison@gmail.com]
> > > > Sent: Tuesday, June 13, 2006 6:34 AM
> > > > To: harmony-dev@incubator.apache.org
> > > > Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent
> > > >
> > > > Nathan Beyer wrote:
> > > > <snip>
> > > > > Does this mean we can stub out the luni-kernel System and just get
> > the
> > > > VMs
> > > > > to implement it in their kernel classes using this method?
> > > >
> > > > That's what I was thinking, and we can implement it in the luni-kernel
> > /
> > > > classpathadapter as a reference for VMs if we so choose.
> > > >
> > > > Regards,
> > > > Tim
> > > >
> > > > --
> > > >
> > > > Tim Ellison (t.p.ellison@gmail.com)
> > > > IBM Java technology centre, UK.
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
> ---------------------------------------------------------------------
> 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
>
>

---------------------------------------------------------------------
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