(11) RFR (S) JDK-8196880: VS2017 Addition of Global Delete Operator with Size Parameter Conflicts with Arena's Chunk Provided One

[Kim Barrett]

> On Feb 16, 2018, at 1:31 PM, coleen.phillimore at oracle.com wrote:
> 
> 
> 
> On 2/16/18 11:28 AM, Lois Foltan wrote:
>> On 2/16/2018 8:43 AM, coleen.phillimore at oracle.com wrote:
>> 
>>> 
>>> This is odd but seems ok.
>>> 
>>> If you make the dummy operator delete private, does it still compile?   If it is actually used, will it get a linktime error rather than a compile time error?
>> Hi Coleen,
>> Thanks for the review.  Yes, making the operator delete private does work and I have updated the webrev.  If it is actually used it will get a linktime error.
>> 
>> Updated webrev at: http://cr.openjdk.java.net/~lfoltan/bug_jdk8196880.1/webrev/
> 
> I like this.   See what Kim says, I guess.  If someone tries to call it they should get a compile time error first.   I believe…

Looks good to me.

> 
> thanks!
> Coleen
> 
>> Lois
>> 
>>> 
>>> thanks,
>>> Coleen
>>> 
>>> On 2/14/18 8:48 AM, Lois Foltan wrote:
>>>> Please review this change in VS2017 to the delete operator due to C++14 standard conformance.  From https://msdn.microsoft.com/en-us/library/mt723604.aspx
>>>> 
>>>> The function|void operator delete(void *, size_t)|was a placement delete operator corresponding to the placement new function "void * operator new(size_t, size_t)" in C++11. With C++14 sized deallocation, this delete function is now a/usual deallocation function/(global delete operator). The standard requires that if the use of a placement new looks up a corresponding delete function and finds a usual deallocation function, the program is ill-formed.
>>>> 
>>>> Thank you to Kim Barrett for proposing the fix below.
>>>> 
>>>> open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8196880/webrev/
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8196880
>>>> 
>>>> Testing complete (hs-tier1-3, jdk-tier1-3)
>>>> 
>>>> Thanks,
>>>> Lois