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

[Dmitry Dmitriev]

Vladimir, thank you for explanation! That makes things clear.

Regards,
Dmitry

On 06.08.2015 1:13, Vladimir Kozlov wrote:
> 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
>>