Assembler_x86.cpp char buffer deallocation

[Vitaly Davidovich]

Got it, thanks for taking the time to explain it.

Cheers,

Vitaly

Sent from my phone
On Oct 9, 2012 2:31 PM, "Vladimir Kozlov" <vladimir.kozlov at oracle.com>
wrote:

> Vitaly Davidovich wrote:
>
>> Ah that makes sense now - thanks! What tripped me up was that I indeed
>> thought this was a runtime call, whereas I realize that this generates code
>> that sticks around and needs to reference this string.
>>
>> Speaking of which, is this technique used for non-debug code? If so,
>>
>
> I think it is only the place where we do this. In other cases (for
> embedded constants) we use _const CodeSection which is part of compiled
> code and will be freed when code is deoptimized.
>
>  what happens if such code is unloaded and this string was only used by
>> that one unloaded blob? Is it somehow deallocated as well?
>>
>
> No deallocation in such case. It is a small memory leak when VerifyOops is
> switched on (it is off by default) in debug VM.
>
> Vladimir
>
>
>> Thanks
>>
>> Sent from my phone
>>
>> On Oct 9, 2012 1:58 PM, "Vladimir Kozlov" <vladimir.kozlov at oracle.com<mailto:
>> vladimir.kozlov@**oracle.com <vladimir.kozlov at oracle.com>>> wrote:
>>
>>     The code is correct. The allocate is normal C++ allocate which use
>>     malloc so the buffer is in C heap.
>>
>>     Again, verify_oop() method is called during assembler code
>>     generation (for example, during JIT compiled code generation). Later
>>     when the compiled code is executed it references this message so it
>>     can print it when oop check in the stub fails.
>>
>>     Think about this as equivalent to C++ code: printf("Message").
>>     "Message" string is kept in .data section whole time of program
>>     execution, it is not deallocated.
>>
>>     Vladimir
>>
>>     Vitaly Davidovich wrote:
>>
>>         Hi Vladimir,
>>
>>         Right, so I did see that this buffer's address is taken and
>>         passed to the stub generator that creates the verify_oop code.
>>          What I couldn't find was where this buffer was deallocated
>>         after the verify_oop procedure was finished.  Since this is
>>         allocated via new(), how would you deallocate it from generated
>>         code since presumably new() can be using a custom allocator
>>         underneath? I realize this is debug code so probably doesn't
>>         matter in practical terms.
>>
>>         I'm a bit unclear on whether you're saying this code is correct
>>         or not. :)
>>
>>         Thanks
>>
>>         Sent from my phone
>>
>>         On Oct 9, 2012 1:09 PM, "Vladimir Kozlov"
>>         <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov@**oracle.com<vladimir.kozlov at oracle.com>
>> >
>>         <mailto:vladimir.kozlov at __orac**le.com <http://oracle.com>
>>         <mailto:vladimir.kozlov@**oracle.com <vladimir.kozlov at oracle.com>>>>
>> wrote:
>>
>>             Vitaly,
>>
>>             It is common mistake to mix code generation time and runtime
>>             execution of the generated code. We need this buffer with a
>>         message
>>             during runtime execution so we can deallocate it during code
>>         generation.
>>
>>             Regards,
>>             Vladimir
>>
>>             Vitaly Davidovich wrote:
>>
>>                 Hi Volker,
>>
>>                 Yes sorry, I should've stated that I did see that it was
>>         guarded
>>                 by VerifyOops and I was just browsing the code - this is
>>         by no
>>                 means some production issue that I have.  Was just
>>         curious if I
>>                 missed something.
>>
>>                 Thanks
>>
>>                 Sent from my phone
>>
>>                 On Oct 9, 2012 9:47 AM, "Volker Simonis"
>>                 <volker.simonis at gmail.com
>>         <mailto:volker.simonis at gmail.**com <volker.simonis at gmail.com>>
>>         <mailto:volker.simonis at gmail._**_com
>>         <mailto:volker.simonis at gmail.**com <volker.simonis at gmail.com>>>
>>                 <mailto:volker.simonis at gmail.
>>         <mailto:volker.simonis at gmail.>**____com
>>                 <mailto:volker.simonis at gmail._**_com
>>         <mailto:volker.simonis at gmail.**com <volker.simonis at gmail.com>>>>>
>> wrote:
>>
>>                     Hi Vitaly,
>>
>>                     it looks not very professional indeed, however it is
>>         only in
>>                 debug
>>                     code or in code protected by development parameters
>>                 (-XX:+VerifyOops)
>>                     so it will not cause any trouble in the production VM.
>>                 Nevertheless it
>>                     should be cleaned up when somebody touches that file.
>>
>>                     Regards,
>>                     Volker
>>
>>                     On Tue, Oct 9, 2012 at 3:10 PM, Vitaly Davidovich
>>                 <vitalyd at gmail.com <mailto:vitalyd at gmail.com>
>>         <mailto:vitalyd at gmail.com <mailto:vitalyd at gmail.com>>
>>                     <mailto:vitalyd at gmail.com <mailto:vitalyd at gmail.com>
>>         <mailto:vitalyd at gmail.com <mailto:vitalyd at gmail.com>>>> wrote:
>>                      > Hi guys,
>>                      >
>>                      > I noticed that assembler_x86.cpp has a few places
>>         where a
>>                 char[]
>>                     is new()'d
>>                      > up to hold an error message when verifying an
>>         oop.  This
>>                 buffer
>>                     is passed to
>>                      > the stub routine, but I can't find where this
>>         buffer is then
>>                      > deleted/deallocated.  Am I missing something?
>>         Apologies
>>                 of this
>>                     is a silly
>>                      > question. :)
>>                      >
>>                      > Thanks
>>                      >
>>                      > Sent from my phone
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20121009/9fffd445/attachment.html