Round 2 Code Review request for new MallocMaxTestWords option and fixed test (7030610, 7037122, 7123945)

David Holmes david.holmes at oracle.com
Mon Mar 18 18:15:42 PDT 2013


Hi Ron,

(fixed subject)

On 19/03/2013 3:25 AM, Ron Durbin wrote:
>> There is a type mismatch between MallocMaxTestWords (uintx) and
>> cur_malloc_words (juint). The former will be 64-bit on 64-bit systems, while the latter is always 32-bit.
>>
>> os.cpp:
>>
>>    580   if (MallocMaxTestWords > 0 &&
>>    581       (cur_malloc_words + (alloc_size / BytesPerWord)) >
>> MallocMaxTestWords) {
>>    582     return false;
>>    583   }
>>
>> this calculation can overflow if MallocMaxWords is close to the limit.
>> Now I doubt we can actually allocate that much but the expression can be rearranged to avoid overflow.
>
> David I do not see the overflow. I see compiler promoting an expression.

Thanks for clarifying. I hadn't picked up that alloc_size was size_t and 
so also potentially 64-bit.

>> Otherwise seems functionally ok but I really hate to see test-only
>> code being injected into a primary execution path like this. Why not move it off to the side:
>>
>> if (MallocMaxTestWords > 0)
>>      return testMalloc(alloc_size);
>>
>> and have
>>
>> void* testMalloc(size_t alloc_size) {
>>     if (!check_malloc_max_test_words(alloc_size)) return NULL;
>>     u_char* ptr = (u_char*)::malloc(alloc_size);
>>     add_current_malloc_test_words(alloc_size, ptr);
>>     return ptr;
>> }

BTW you would of course just inline those other methods.
>
>
>
> For the above comments, the code is structured the way Coleen requested and I'm deferring to her judgement.

Paging Coleen :)

Thanks,
David
------


More information about the hotspot-runtime-dev mailing list