Assembler_x86.cpp char buffer deallocation

[Vladimir Kozlov]

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 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 at oracle.com>
>         <mailto:vladimir.kozlov at __oracle.com
>         <mailto: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>
>         <mailto:volker.simonis at gmail.__com
>         <mailto: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>>>> 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
>