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

[Vladimir Kozlov]

By suggestion from Aleksey we are pushing this into jdk9/dev directly to 
get it for promotion testing this week:

Aleksey Voytilov wrote:
 > Vladimir, if this fix can help with AOT stability, do you think we 
could get it in /dev before promotion starts? I'd like not to waste our 
lab running bigapps for weeks with known stability issues.

Note, this is AOT related changes. And Alexey is talked about additional 
bigapps testing which will use aoted java.base module.
Normal testing should not be affected since AOT is off by default 
(unless AOT libraries are present).

Thanks,
Vladimir

On 12/20/16 8:35 PM, dean.long at oracle.com wrote:
> Thanks Tom.
>
> dl
>
>
> On 12/20/16 8:30 PM, Tom Rodriguez wrote:
>>
>>> On Dec 20, 2016, at 7:01 PM, dean.long at oracle.com
>>> <mailto:dean.long at oracle.com> wrote:
>>>
>>> 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 <mailto: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?
>>
>> From the perspective of code generation the allocation paths do this.
>>  But to answer my own question, I think c2 may be setting it to true
>> under conditions where it will never be consulted.  Any VM entry point
>> that actually returns an oop uses a stub to handle it and passes the
>> value through vm_result so it’s handled across the safe point.  You
>> can't actually stop at the call site pc when you deoptimize.  I think
>> a correct value is only required for real Java invoke sites.
>>
>>>
>>>> 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”);
>>
>> The code is using isa_ptr() so any pointer return value will set it to
>> true which is clearly wrong.  I suspect any path which might set this
>> incorrectly simply will never consult the value.
>>
>> So I think your fix for JVMCI looks right.  And the existing C2 code
>> is benignly wrong.
>>
>> tom
>>
>>>
>>> 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
>>>>>> <mailto: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
>>
>