RFR (XXS): 8075288: malloc without free in VM_PopulateDumpSharedSpace::doit()

[Jungwoo Ha]

Carsten,

I do not understand this code very well.
I just find malloc() without free() from the source code.


On Fri, Apr 10, 2015 at 7:49 AM, Carsten Varming <varming at gmail.com> wrote:

> Dear Jungwoo,
>
> Why is this array not resource allocated?
>
> Carsten
>
> On Fri, Apr 10, 2015 at 9:31 AM, Jungwoo Ha <jwha at google.com> wrote:
>
>> What's the conclusion? Should I fix it or discuss it separately?
>>
>> On Thu, Apr 9, 2015 at 2:43 PM, Kim Barrett <kim.barrett at oracle.com>
>> wrote:
>>
>>> On Apr 9, 2015, at 1:25 PM, Jungwoo Ha <jwha at google.com> wrote:
>>> >
>>> > Can someone sponsor this change?
>>> >
>>> > https://bugs.openjdk.java.net/browse/JDK-8075288
>>> > http://cr.openjdk.java.net/~jwha/8075288/webrev.00
>>>
>>> I think the change is correct.  Good find!
>>>
>>> However, it’s not clear to me why this is using malloc (and now free),
>>> rather than stack allocation.
>>> The size is a declared variable at the allocation point, but it’s
>>> initialized from a constant with a
>>> not big value (17) and never modified, so could be changed to be a
>>> constant.
>>>
>>> That is, instead of
>>>
>>>  592   char* saved_vtbl = (char*)os::malloc(vtbl_list_size *
>>> sizeof(void*), mtClass);
>>>  593   memmove(saved_vtbl, vtbl_list, vtbl_list_size * sizeof(void*));
>>>
>>> use
>>>
>>>   void* saved_vtbl[vtbl_list_size];
>>>   memmove(saved_vtbl, vtbl_list, ARRAY_SIZE(saved_vtbl));
>>>
>>> Maybe the worry is that vtbl_list_size might not always be a small
>>> constant?
>>>
>>> Probably this question of whether to use malloc/free here at all should
>>> be a separate CR.
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150410/17f2af39/attachment.htm>