Request for review (S): 7100935: win32: memmove is not atomic but is used for pd_conjoint_*_atomic operations
tom.rodriguez at oracle.com
Wed Oct 19 09:56:41 PDT 2011
On Oct 18, 2011, at 11:47 PM, David Holmes wrote:
> Hi Axel,
> On 18/10/2011 11:15 PM, Siebenborn, Axel wrote:
>> 7100935: win32: memmove is not atomic but is used for pd_conjoint_*_atomic.
>> The fix is to replace the call to memmove by a simple copy loop.
>> I made the fix for windows_x86_64 and for sparc.
> x86_32 is fixed too :)
>> I added the tests for copying oops and the copy of short arrays of Volker.
>> I did not use the template of my original change.
>> However, win compiler would inline the template and so does gcc. It's strange, that Sun's compiler doesn't.
> The code changes look okay to me too.
> 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.
More information about the hotspot-runtime-dev