harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rana Dasgupta" <rdasg...@gmail.com>
Subject Re: [general] What platforms do we support?
Date Thu, 05 Apr 2007 22:39:26 GMT
On 4/5/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> On Thursday 05 April 2007 00:48 Rana Dasgupta wrote:
> > On 4/4/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> > > On Wednesday 04 April 2007 23:33 Rana Dasgupta wrote:
> > > > On 4/4/07, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > > > > On 4/4/07, Alexey Petrenko <alexey.a.petrenko@gmail.com> wrote:
> > > > > > 2007/4/4, Gregory Shimansky <gshimansky@gmail.com>:
> > > > > > > > > I would like to see these modifications. I wonder
what you've
> > > > > > > > > done in
> > > > > > >
> > > > > > > port/src/thread/linux/apr_thread_ext.c and
> > > > > > > vmcore/include/atomics.h. They contain mfence and sfence
> > > > > > > instructions in inline assembly which have to be changed
to
> > > > > > > something else on P3.
> > > >
> > > > MemoryWriteBarrier() etc. should be no-ops on PIII. x86 is already
> > > > strongly ordered for writes ?
> > >
> > > What about MemoryReadWriteBarrier()? If you know, what kind of code
> > > should be used for this in P3?
> >
> > One of the compiler guys can confirm this. But I don't believe that
> > you need to worry about any of the fence instructions fence on any of
> > the PIII, PIV genuine intel procs unless you are using streaming mode
> > ( SIMD ) instructions which are weakly ordered.
>
> I actually grepped the use for MemoryReadWriteBarrier, MemoryWriteBarrier and
> apr_memory_rw_barrier functions which are wrappers to mfence/sfence
> instructions. They aren't used in the code which uses SSE2 in any way.
>
> - The apr_memory_rw_barrier (executes mfence) function is used in thin locks
> implementation in threading code.
>
> - MemoryReadWriteBarrier (executes mfence) is used in
> org.apache.harmony.util.concurrent natives implementation after
> writing/reading int/long/object fields via JNI.
>
> - MemoryWriteBarrier (executes sfence) is used in classloader for fast
> management of classes collection and in strings pool for the same reason.
>
> In all three cases SSE2 is not involved in any way, simply loads and stores
> are done with the memory. According to you in all of those cases memory
> barriers are not needed. I am just confused then why were they inserted in
> those places?

I don't know the answer to this question ...unless it was intended to
cover clones etc. that don't fully support the writeback model...
>
> --
> Gregory
>

Mime
View raw message