RFR: 8227168: Cleanup usage of NEW_C_HEAP_ARRAY
Leo Korinth
leo.korinth at oracle.com
Wed Sep 4 11:21:14 UTC 2019
On 04/09/2019 05:35, David Holmes wrote:
> I'll concur with Kim on this. Restore the comment in allocation.hpp
> despite the inaccuracy - or else fix the blatant errors but don't worry
> about elaborating on missing macros.
>
> Thanks,
> David
how about:
//NEW_RESOURCE_ARRAY*
//REALLOC_RESOURCE_ARRAY*
//FREE_RESOURCE_ARRAY*
//FREE_FAST
//NEW_RESOURCE_OBJ*
//NEW_C_HEAP_ARRAY*
//REALLOC_C_HEAP_ARRAY*
//FREE_C_HEAP_ARRAY*
//NEW_C_HEAP_OBJ*
//FREE_C_HEAP_OBJ
//
//char* AllocateHeap(size_t size, MEMFLAGS flags, const NativeCallStack&
stack, AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM);
//char* AllocateHeap(size_t size, MEMFLAGS flags, AllocFailType
alloc_failmode = AllocFailStrategy::EXIT_OOM);
//char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag,
AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM);
It is (at least) better than what is present, I could also list them all:
//NEW_RESOURCE_ARRAY(type, size)
//NEW_RESOURCE_ARRAY_RETURN_NULL(type, size)
//NEW_RESOURCE_ARRAY_IN_THREAD(thread, type, size)
//NEW_RESOURCE_ARRAY_IN_THREAD_RETURN_NULL(thread, type, size)
//REALLOC_RESOURCE_ARRAY(type, old, old_size, new_size)
//REALLOC_RESOURCE_ARRAY_RETURN_NULL(type, old, old_size, new_size)
//FREE_RESOURCE_ARRAY(type, old, size)
//FREE_FAST(old)
//NEW_RESOURCE_OBJ(type)
//NEW_RESOURCE_OBJ_RETURN_NULL(type)
//NEW_C_HEAP_ARRAY3(type, size, memflags, pc, allocfail)
//NEW_C_HEAP_ARRAY2(type, size, memflags, pc)
//NEW_C_HEAP_ARRAY(type, size, memflags)
//NEW_C_HEAP_ARRAY2_RETURN_NULL(type, size, memflags, pc)
//NEW_C_HEAP_ARRAY_RETURN_NULL(type, size, memflags)
//REALLOC_C_HEAP_ARRAY(type, old, size, memflags)
//REALLOC_C_HEAP_ARRAY_RETURN_NULL(type, old, size, memflags)
//FREE_C_HEAP_ARRAY(type, old)
//NEW_C_HEAP_OBJ(type, memflags)
//NEW_C_HEAP_OBJ_RETURN_NULL(type, memflags)
//FREE_C_HEAP_OBJ(objname)
//
//char* AllocateHeap(size_t size, MEMFLAGS flags, const NativeCallStack&
stack, AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM);
//char* AllocateHeap(size_t size, MEMFLAGS flags, AllocFailType
alloc_failmode = AllocFailStrategy::EXIT_OOM);
//char* ReallocateHeap(char *old, size_t size, MEMFLAGS flag,
AllocFailType alloc_failmode = AllocFailStrategy::EXIT_OOM);
I propose the first shorter (asterisked) version.
Thanks,
Leo
> On 4/09/2019 4:33 am, Kim Barrett wrote:
>>> On Sep 3, 2019, at 12:12 PM, Leo Korinth <leo.korinth at oracle.com> wrote:
>>>
>>> On 03/09/2019 01:46, Kim Barrett wrote:
>>>>> On Sep 2, 2019, at 5:59 PM, David Holmes <david.holmes at oracle.com>
>>>>> wrote:
>>>>> On 2/09/2019 10:23 pm, Leo Korinth wrote:
>>>>>> Hi!
>>>>>> After I got caught doing an unnecessary check on the return value
>>>>>> of NEW_C_HEAP_ARRAY (a mistake that I copied) I thought it would
>>>>>> be good to do a cleanup in the sources so that others would not
>>>>>> fall into this trap. This is the result.
>>>>>> I have removed some places where the VM will be shut down after
>>>>>> NEW_C_HEAP_ARRAY returns NULL (it never does return NULL, it does
>>>>>> instead exit). I have also removed lots of unnecessary casts, that
>>>>>> might hide bugs.
>>>>>
>>>>> Those changes all seem fine, as are the perfMemory changes.
>>>>>
>>>>> My only issue is with the places where you can changed allocation
>>>>> of a NEW_C_HEAP_ARRAY of size 1 to a NEW_C_HEAP_OBJ. They are still
>>>>> freed with FREE_C_HEAP_ARRAY which looks odd even though correct
>>>>> (in that it's all os::free under the covers anyway). I'm not sure
>>>>> this change is worth the potential confusion it may cause.
>>>> I noticed that too, and then forgot about it. I agree that’s not
>>>> right. I think those places
>>>> should be changed to use FREE_C_HEAP_OBJ for the deallocation.
>>>
>>> Thank you for finding this. I actually considered implementing the
>>> macro FREE_C_HEAP_OBJ as I could not find it. Now I can not
>>> understand how I could /miss/ it, though I guess I was looking for a
>>> macro with the same signature as FREE_C_HEAP_ARRAY (one taking the
>>> type as argument) :-(
>>>
>>> As a consequence I also deleted some outdated help text:
>>>
>>> - // NEW_RESOURCE_ARRAY(type, size)
>>> - // NEW_RESOURCE_OBJ(type)
>>> - // NEW_C_HEAP_ARRAY(type, size)
>>> - // NEW_C_HEAP_OBJ(type, memflags)
>>> - // FREE_C_HEAP_ARRAY(type, old)
>>> - // FREE_C_HEAP_OBJ(objname, type, memflags)
>>> - // char* AllocateHeap(size_t size, const char* name);
>>> - // void FreeHeap(void* p);
>>
>> I think just deleting the list of macros and functions isn't right.
>> Doing so leaves the preceeding two paragraphs dangling, e.g. "The
>> following macros and function ...".
>>
>> That whole section of the comment could use some TLC. That doesn't
>> need to be part of this change.
>>
>>> 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.
>>
>> I think create_multi_counter_query is only paired with the appropriate
>> overload of destroy_counter_query, and could use NEW/FREE_C_HEAP_OBJ.
>>
>> The array case only seems to arise with the set member of
>> MultiCounterQuerySet, which uses NEW/FREE_C_HEAP_ARRAY (in
>> destroy_multi_counter_query, which is strictly a helper for some
>> overloads of destroy_counter_query where an array is involved.
>>
>> But I can see why you might take the simple approach here. I wonder
>> why the query types are POD with all these file-scoped create/destroy
>> helper functions, rather than having constructors and destructors. I
>> suspect that would make these questions around the lifetime management
>> much simpler.
>>>
>>> Incremental:
>>> http://cr.openjdk.java.net/~lkorinth/8227168/00_01/
>>>
>>> Full:
>>> http://cr.openjdk.java.net/~lkorinth/8227168/01/
>>>
>>> rerunning tests...
>>>
>>> Thanks, Leo
>>
>> Other than the partial comment deletion, this looks good to me.
>>
>> I don’t need a new webrev if you are just going to reinstate that
>> partial comment.
>>
More information about the hotspot-dev
mailing list