Assembler_x86.cpp char buffer deallocation

[Vitaly Davidovich]

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, what
happens if such code is unloaded and this string was only used by that one
unloaded blob? Is it somehow deallocated as well?

Thanks

Sent from my phone
On Oct 9, 2012 1:58 PM, "Vladimir Kozlov" <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>>> 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>>>>
>> 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>>> 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/6d54fa99/attachment.html