RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY

[coleen.phillimore at oracle.com]

On 9/4/19 7:16 AM, Leo Korinth wrote:
>
>
> On 03/09/2019 20:07, Kim Barrett wrote:
>>> On Sep 3, 2019, at 1:19 PM, coleen.phillimore at oracle.com wrote:
>>> On 9/3/19 12:12 PM, Leo Korinth wrote:
>>>> I have tried to use FREE_C_HEAP_OBJ correctly, and I did revert one 
>>>> usage of NEW_C_HEAP_OBJ to NEW_C_HEAP_ARRAY as it seemed to be able 
>>>> to also be an array type when allocated in another place.
>>>
>>> […]  But I don't agree.  I don't think NEW_C_HEAP_ARRAY should be 
>>> used to allocate and FREE_C_HEAP_OBJ should be used to deallocate.  
>>> That's worse.
>>
>> That wasn’t what was suggested.  The suggestion was to always be 
>> consistent with the pairing,
>> e.g. use NEW_C_HEAP_ARRAY and FREE_C_HEAP_ARRAY for an object, or use 
>> NEW_C_HEAP_OBJ
>> and FREE_C_HEAP_OBJ, but never mix the pairings for a given object.  
>> I think that’s what the
>> updated change is doing.
>
> That was what I tried to do, your explanation is much better than 
> mine, thanks Kim.
>>
>>> Actually, I think neither NEW_C_HEAP_OBJ or FREE_C_HEAP_OBJ should 
>>> exist.  They should just use new Type(), where Type is inherited 
>>> from CHeapObj<mtAppropriate>
> It is my goal to remove /all/ allocation macros, but I could not fit 
> it into this change ;-)

How are you going to remove the NEW_C_HEAP_ARRAY macros?  Is that 
somewhere in this thread?  Everything got cut off.  Can you put all this 
in the CR?

What is the latest version of this patch?

Thanks,
Coleen


>
> Thanks, Leo
>>
>> I was expecting that to have widespread impact, but it seems there 
>> are far fewer uses of NEW_C_HEAP_OBJ
>> than I was expecting.  But I suggest that doing anything about that 
>> is out of scope for this change.
>>
>> I’m also not really fond of the allocation base class approach; C++11 
>> allows some alternatives.
>>