Question regarding "native-compiled frame"
Felix Yang
felix.yang at linaro.org
Sat Sep 16 09:43:42 UTC 2017
On 16 September 2017 at 02:15, Chris Plummer <chris.plummer at oracle.com>
wrote:
> On 9/13/17 6:10 AM, Felix Yang wrote:
>
>> On 7 September 2017 at 19:04, Andrew Dinn <adinn at redhat.com> wrote:
>>
>> On 07/09/17 11:35, Felix Yang wrote:
>>>
>>>> Thanks for the reply.
>>>> Then when will the last return statement of frame::sender got a
>>>> chance
>>>>
>>> to
>>>
>>>> be executed?
>>>> As I see it, when JVM does something in safepoint state and need to
>>>> traverse Java thread stack, we never calculate the sender of a
>>>> native-compiled frame.
>>>>
>>> It is possible for Java to call out into the JVM and then for the JVM to
>>> call back into Java. For example, when a class is loaded the JVM calls
>>> into Java to run the class initializer. This re-entry may happen
>>> multiple times.
>>>
>>> In that case a stack walk under the re-entry may find a Java start fame
>>> and it's parent frame will be the native frame where Java entered the VM.
>>>
>>> Yes, that's the frame structure.
>>
>>
>> Note that the native frame will always be returned by the call to
>>> sender_for_entry_frame(map). That method skips all the C frames between
>>> the Java entry frame and the native frame which exited Java.
>>>
>>> True. And this is handled by the three IF statements of frame::sender
>> function.
>> It seems to me that the last return statement is not involved in the stack
>> walking process, isn't it?
>>
> Hi Felix,
>
> Are you talking about the following:
>
> // Must be native-compiled frame, i.e. the marshaling code for native
> // methods that exists in the core system.
> return frame(sender_sp(), link(), sender_pc());
>
Yes, I want to know which kind of frame we are handling here.
>
> If so, the Oracle arm port used to have this same code. However, 2-3 years
> ago I was doing quite a few fixes to arm stack/frame walking, and suspected
> this code was never executed. In 9 I changed to:
>
> assert(false, "should not be called for a C frame");
> return frame();
>
> We've never hit this assert in all our testing since. Possibly this change
> could also be made to x86. However, the details of why I thought this
> change was ok has escaped me.
Thanks for this helpful information.
I performed JTreg and specjbb test and I find this code never hit on x86
platform.
So I also think of this return statement for x86 as dead code. Don't know
why the code is there.
Thanks for your help,
Felix
More information about the hotspot-dev
mailing list