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

[Vladimir Kozlov]

I don't see how debug64 is not executed if stop is called:

void MacroAssembler::stop(const char* msg) {
   address rip = pc();
   pusha(); // get regs on stack
   lea(c_rarg0, ExternalAddress((address) msg));
   lea(c_rarg1, InternalAddress(rip));
   movq(c_rarg2, rsp); // pass pointer to regs array
   andq(rsp, -16); // align stack as required by ABI
   call(RuntimeAddress(CAST_FROM_FN_PTR(address, MacroAssembler::debug64)));
   hlt();
}

Looks like you misunderstand how this code works. You can't use tty->print_cr() in these cases. It produce output when 
that assembler code is *generated* and NOT when it is *executed*.

Saying that I realized that your fix is totally wrong. Buffer allocation happens during assembler code generation but it 
is used when that code is executed. If you free it (during code generation) you will get bad pointer during execution 
because corresponding memory is freed.

In this regards it is NOT memory leak. We need this memory during whole run until JVM exit (end of program).
This code is used for adapter generation which are never not removed from CodeCache.

Regards,
Vladimir

On 8/5/15 2:41 PM, Dmitry Dmitriev wrote:
> 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
>