RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks

Vladimir Kozlov vladimir.kozlov at oracle.com
Tue Dec 20 23:34:34 UTC 2016


On 12/20/16 1:44 PM, Tom Rodriguez wrote:
>
>> On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>
>> Thank you, Dean, for finding the cause.
>>
>> Looks good to me.
>>
>> CCing to Graal since it affects it. I am curious why Labs did not hit it before.
>
> Not sure either, though AOT’s been running for a while without seeing it either.
>
> I’m a unsure that this is the right logic though.  If you look at how C2 is setting this flag it’s driven by lower level code generation details.  Basically it’s looking at the underlying call object at the debug info site to determine if that call is returning an oop.  Will that produce the same answer as checking the return type of the call?  For any site which is a normal method invoke I think it will but what about other calls like a vm entry point?

I agree, C2 is checking is_ptr() which include metadata pointers.

In such case we need help from you. I think pointer return information 
can be recorded in DebugInfo or Call class.

Thanks,
Vladimir

>
> tom
>
>>
>> Thanks,
>> Vladimir
>>
>> On 12/19/16 1:22 PM, dean.long at oracle.com wrote:
>>> AOT code, like C2 code, can reallocate objects during deoptimization,
>>> because of escape analysis.  To support this, we need to set the
>>> "return_oop" flag on the scope correctly.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8169938
>>> http://cr.openjdk.java.net/~dlong/8169938/webrev/
>>>
>>> dl
>>>
>


More information about the hotspot-compiler-dev mailing list