harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <ndbe...@apache.org>
Subject Re: [general] What platforms do we support?
Date Fri, 06 Apr 2007 21:39:12 GMT
On 4/6/07, Gregory Shimansky <gshimansky@gmail.com> wrote:
> On Friday 06 April 2007 02:39 Rana Dasgupta wrote:
> > 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...
>
> I should have put the question in a different way. I didn't actually mean that
> you should know why some code is written in VM. I don't know why some code is
> written in many places including those I mentioned.
>
> The question should actually be like, should we actually remove mfence and
> sfence assembly instructions from the VM sources for x86/x86_64 platforms? I
> commented mfence in port/src/thread/linux/apr_thread_ext.c and mfence/sfence
> in vmcore/include/atomics.h and ran VM tests on 5 different SMP boxes with no
> less than 4 logical CPUs on each of them (2 win32, linux32, windows64 and
> linux64). Tests seem to work just fine without mfence and sfence in VM code.
>
> With these instructions removed from the code there shall be no problem with
> P3 port on VM side. It seems they are actually unnecessary and were inserted
> for a reason that they help on SMP to synchronize caches. After your
> explanation that they are actually needed only when SSE2 is involved, it
> seems (and my tests show this) that they are just not needed.
>
> --
> Gregory
>

Well, we all know that executing incorrect concurrency code and not
seeing any errors or side-effects isn't a guarantee of correctness,
but the anecdotal evidence is compelling.

What was the change you made specifically? Did you also remove the
other barrier calls that were used in some cases for 64-bit platforms?

If there's any methods that are NOT being used and not a part of a
required API, then we should definitely eliminate those as it's just
cruft. As for those bits of code that are in the execution path, does
anyone know why the code was originally introduced and what the need
was? This would've been a great place for some code comments. :(

-Nathan

Mime
View raw message