[OpenJDK 2D-Dev] [9] Review Request: 8080847 Copying of overlapping memory should be improved in java2d

[Jim Graham]

I'm sorry, but memcpy has never crashed simply due to overlapping 
regions and there is no evidence for this.  We've been using it for 
nearly 20 years now and never had a crash when the src and dst memory 
regions are within the bounds of an image.

You are taking language meant to cover them for "we do not guarantee 
that overlapping memory copies won't make a mess of the data you are 
copying" to somehow infer that it can read or write outside the 
indicated bounds.  At worst the pixels will be jumbled and that would 
not cause any crashes, it would simply look wrong on the screen.  The 
thread that Sergey pointed to even went so far as to have developers 
claim that the exact specific way that it jumbles the data it is copying 
is considered part of the contract even though the behavior is specified 
as undefined.  Crashing is completely outside the scope of its undefined 
claim.

The only viable reason for switching to memmove is to either silence the 
tool that reported the issue or to fix the data ordering issue.  There 
are other ways to silence the tool without making one of our blits have 
behavior that doesn't match other similar blits, and if we are going to 
fix the data ordering issue we should do it for all blits...

		...jim

On 5/28/2015 12:58 AM, Andrew Haley wrote:
> On 28/05/15 01:06, Jim Graham wrote:
>> Where do you see evidence that it can crash?
>
> It's what the language specification says.  Undefined behaviour is
> unconstrained: it can do anything.  Demons might fly out of your nose.
>
> We have seen with GCC that apparently "harmless" code (a read just
> beyond the end of an array) can, for example, result in an infinite
> loop.  In this case, it is quite possible that GCC could infer that
> the two memory regions accessed by memcpy do not overlap.
>
> Andrew.
>