[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Request for review (S): 7100935: win32: memmove is not atomic but is used for  pd_conjoint_*_atomic
From:       david.holmes () oracle ! com (David Holmes)
Date:       2011-10-20 2:32:12
Message-ID: 4E9F882C.4080705 () oracle ! com
[Download RAW message or body]

On 20/10/2011 10:09 AM, Tom Rodriguez wrote:
> On Oct 19, 2011, at 4:52 PM, David Holmes wrote:
> > 
> > On 20/10/2011 2:56 AM, Tom Rodriguez wrote:
> > > On Oct 18, 2011, at 11:47 PM, David Holmes wrote:
> > > > I have a slight issue with the tests. Both tests are set to run with -Xint, \
> > > > but for windows this impacts compiled code as well (as far as I can see on \
> > > > Windows C1/C2 do not intrinsify these operations and so use the runtime \
> > > > pd_conjoint_*_atomic functions). Not quite sure how to handle this - I'll \
> > > > look into and get back to you.
> > > 
> > > Both C1 and C2 heavily optimize arraycopy.  C1 and C2 will never use those \
> > > routines except in cases where the type of src and dst is actually Object, such \
> > > that we'd fallback to the System.arraycopy native method.  In all other cases \
> > > it will bind to the appropriate element wise copy routine based on the visible \
> > > types.  I think there should already be a test case that exercises this issue \
> > > in the compiler but I can't find it.  Anyway, testing it here as well is \
> > > probably a good idea.
> > 
> > I see TestShortArrayCopy fail on windows using -Xcomp. It doesn't use Object[] so \
> > what code will C1/C2 use? (both can fail) If they are using intrinsics then we \
> > have a secondary problem.
> 
> Is it failing with -client or -server?  Is it failing in a fixed JVM?    Remember \
> that -Xcomp with -server may still spend some time in the interpreter, potentially \
> using the broken path.  The optimized path uses StubRoutines::*_short_*_arraycopy \
> depending on the particulars of the call site.  Those routines always do element \
> wise copies and are the same on all os'es.

It fails with both client and server, but as Tom has explained offline 
both compilers will in some cases fallback to using the broken code. In 
this case the use of Xcomp doesn't guarantee that only compiled versions 
of the code will be used.

So my mind is at ease that this fix is complete.

Thanks,
David
-----

> Note that I said it falls back to arraycopy for Object, not Object[].  Object[] \
> will attempt to use an optimized path but in some cases may fall back to the native \
> version, particularly if dynamic type checks are required on every store but even \
> that is generally handled in hand written assembly these days. 
> tom
> 
> 
> > 
> > David
> 


[prev in list] [next in list] [prev in thread] [next in thread]