Request for review (S): 7100935: win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations

[Tom Rodriguez]

On Oct 19, 2011, at 4:52 PM, David Holmes wrote:

> Hi Tom,
> 
> 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.

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