RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace()

[mikhailo.seledtsov at oracle.com]

Also, adding jfr-dev list.

On 8/9/19 2:00 PM, mikhailo.seledtsov at oracle.com wrote:
> Looks good to me,
>
> Thank you,
>
> Misha
>
> On 8/9/19 6:56 AM, Baesken, Matthias wrote:
>>
>> Hello, please review this small  test adjustment .
>>
>> The TestShutdownEvent.java  JFR test  fails now and then  in the  
>> sub-test   “TestVMCrash” .
>>
>> Error  is in the stack validation , it  finds sometimes a stack with 
>> no frames .
>>
>> at 
>> jdk.jfr.event.runtime.TestShutdownEvent.validateStackTrace(TestShutdownEvent.java:128) 
>>
>> at 
>> jdk.jfr.event.runtime.TestShutdownEvent$TestVMCrash.verifyEvents(TestShutdownEvent.java:172) 
>>
>>
>> Our conclusion so far is that it is currently not 100% reliable to 
>> get a stack trace in this case using vframeStream in 
>> jfrStackTraceRepository.cpp
>>
>> (forced crash with Unsafe + event generation using EventShutdown late 
>> in VMError.cpp ) .
>> Reason is that  we might  get  compiled frames  on the stack and   
>> then  the  vframeStream – based  solution  does not work ( when  
>> running with -Xcomp  it always fails).
>>
>> See also  the comments of our JIT expert Martin  in the  bug :
>>
>> “JfrStackTrace uses vframeStream to retrieve the stack frames.
>> This works fine if a native frame is on top (because we have the last 
>> Java frame linked in the JavaThread object).
>> That's why the tests works when executed with -Xint. The crashing 
>> method is native in this case.
>>
>> The situation is different when there's a compiled frame on top.
>> JIT compilers usually inline Unsafe accesses as instrinsics. So the 
>> crashing instruction is just in the middle of a compiled method.
>> The vframeStream API would require a PC for which additional 
>> information is available (see CodeEmitInfo for C1 or JVMState for C2).
>> That's not the case for an illegal Unsafe access which simply yields 
>> undefined behavior. Vframes are not supported in this case so the 
>> stack trace is empty.
>>
>> It is possible to get a native stack trace (see 
>> VMError::print_native_stack which doesn't use vframes) for hs_err 
>> files. Compiled frames are only shown as single
>>
>> frames even if multiple Java frames are included due to inlining.
>>
>> Note that the test always fails when using -Xcomp. So it doesn't make 
>> any sense to expect a non-empty vframe based stack trace when a 
>> compiled frame is on top. “
>>
>> My first idea   was to run the  test  with -Xint  but its probably 
>> not such a good idea ; so better  for now   remove  the  unreliable 
>> check  (  + add a comment ).
>>
>> Thanks, Matthias
>>
>> Bug/webrev :
>>
>> https://bugs.openjdk.java.net/browse/JDK-8219082
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8219082.1/
>>