RFR (XXS): 8132728: Memory leak in MethodHandles::verify_ref_kind function(fastdebug build)

[Dmitry Dmitriev]

Hello Vladimir,

Thank you for review and explanation!

I looked at the code and see that code does not return from STOP and 
this block executed only when ref kind not equal to expected. But it is 
possible that debug64 will not be called and execution continues? For 
example at VM start-up? Here a call chain which I see:
JVM_RegisterMethodHandleMethods->MethodHandles::generate_adapters->MethodHandlesAdapterGenerator::generate->MethodHandles::generate_method_handle_interpreter_entry->MethodHandles::verify_ref_kind

For quick experiment I add tty->print_cr() to the 
MethodHandles::verify_ref_kind, MacroAssembler::stop and 
MacroAssembler::debug64 and see that block with memory allocation is 
executed in this case, stop method is called, but debug64 is not 
executed and stop successfully finished. So, it explains why I see 
memory leak... Correct me if I am wrong. Thanks!

Dmitry

On 05.08.2015 20:54, Vladimir Kozlov wrote:
> Looks good.
>
> Note, it is not real memory leak - code does not return from STOP 
> call. It either produce assert and exit or wait to attach debugger 
> (ShowMessageBoxOnError). See MacroAssembler::debug64() for example.
>
> Thanks,
> Vladimir
>
> On 8/5/15 9:55 AM, Dmitry Dmitriev wrote:
>> Hello,
>>
>> Please review this fix which remove small memory leak in debug build. 
>> Also, I need a sponsor for this fix, who can push it.
>>
>> MethodHandles::verify_ref_kind contains memory leak. Memory for 'buf' 
>> is allocated by NEW_C_HEAP_ARRAY but not freed
>> after '__ STOP(buf);'.
>>
>> Webrev: http://cr.openjdk.java.net/~ddmitriev/8132728/webrev.00/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8132728
>> Tested: JPRT(hotspot test set), hotspot all, vm.quick
>>
>> Thanks,
>> Dmitry