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

[dean.long at oracle.com]

On 12/20/16 3:34 PM, Vladimir Kozlov wrote:

> 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?
>

Is there a VM entry point that returns an oop in a register?

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

It must be an oop, not metadata:

         oop result = deoptee.saved_oop_result(&map);
         assert(result == NULL || result->is_oop(), "must be oop");

dl

> 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
>>>>
>>