RFR (XXS): 8075288: malloc without free in VM_PopulateDumpSharedSpace::doit()
jwha at google.com
Fri Apr 10 16:46:08 UTC 2015
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?
> 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>
>>> 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
>>> 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*));
>>> 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
>>> Probably this question of whether to use malloc/free here at all should
>>> be a separate CR.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev