JDK-8153167 : Allow stack walking pass through method handle intrinsic frames
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • CPU: x86
  • Submitted: 2016-03-31
  • Updated: 2020-05-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Blocks :  
Relates :  
Relates :  
Description
JDK-8068945 has changed the frame::safe_for_sender method in frame_x86.cpp to not consider method handle intrinsics as "safe for sender".

http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/382e9e4b3b71/src/cpu/x86/vm/frame_x86.cpp#l228

This bug is supposed to investigate if that change was necessary and, if not, if it can be removed.

The possible problem was noticed by Tobias Hartmann.
Comments
[~vlivanov], any thoughts on this? I'll run the JFR tests to see if they exercise that code.
28-02-2018

ILW=incomplete stack trace;MH intrinsics;none=M/LMH=>P3/5=P4
04-04-2016

The issue was triggered by an unmodified build as well (b112), so I've filed a bug for that (JDK-8153270). Unfortunately, I can't continue working on this issue until JDK-8153270 is not fixed.
01-04-2016

I tried the following patch: http://cr.openjdk.java.net/~zmajo/8153167/webrev.00/ and I get the following error message: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xffff80ff4939ec65, pid=7477, tid=2 # # JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-03-31-094227.zmajo.8153167) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-03-31-094227.zmajo.8153167, compiled mode, tiered, compressed oops, g1 gc, solaris-amd64) # Problematic frame: # C 0xffff80ff4939ec65 # # Core dump will be written. Default location: /tmp/zmajo/8153167/core or core.7477 # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- S U M M A R Y ------------ Command Line: -agentlib:collector -Xcomp -XX:-PreserveFramePointer LongLambdaFormDynamicStackDepth 1000 Host: intelsdv02, x86 64 bit 2926 MHz, 16 cores, 31G, Oracle Solaris 11.1 X86 Time: Thu Mar 31 13:38:37 2016 UTC elapsed time: 22 seconds (0d 0h 0m 22s) --------------- T H R E A D --------------- Current thread (0x000000000043b000): JavaThread "main" [_thread_in_vm, id=2, stack(0xffff80ffbed4f000,0xffff80ffbee4f000)] Stack: [0xffff80ffbed4f000,0xffff80ffbee4f000], sp=0xffff80ffbee47b28, free space=994k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C 0xffff80ff4939ec65 V [libjvm.so+0x1cda89f] int Method::bci_from(unsigned char*)const+0x7f V [libjvm.so+0x1cda9a3] int Method::validate_bci_from_bcp(unsigned char*)const+0x63 V [libjvm.so+0x15ab8bc] bool frame::is_interpreted_frame_valid(JavaThread*)const+0xbc V [libjvm.so+0x15a9efa] bool frame::safe_for_sender(JavaThread*)+0x31a V [libjvm.so+0x159816a] void forte_fill_call_trace_given_top(JavaThread*,ASGCT_CallTrace*,int,frame)+0x5ba V [libjvm.so+0x1598b23] AsyncGetCallTrace+0x243 C [libcollector.so+0x30905] __collector_ext_jstack_unwind+0x115 C [libcollector.so+0x3123a] __collector_get_frame_info_walk+0x26a C [libcollector.so+0x3e4f8] __collector_getUserCtx+0x28 C [libcollector.so+0x1f22c] __collector_ext_profile_handler+0x13c C [libcollector.so+0x19f3f] collector_sigprof_dispatcher+0x6f C [libc.so.1+0x122476] __sighndlr+0x6 C [libc.so.1+0x115972] call_user_handler+0x2ce C [libc.so.1+0x115e1b] sigacthandler+0xdb C 0xffffffffffffffff V [libjvm.so+0x1edb3b5] char*ResourceArea::allocate_bytes(unsigned long,AllocFailStrategy::AllocFailEnum)+0x185 V [libjvm.so+0x1d51242] void nmethod::check_all_dependencies(DepChange&)+0x362 V [libjvm.so+0x13a242f] int CodeCache::mark_for_deoptimization(KlassDepChange&)+0x10f V [libjvm.so+0x13a324a] void CodeCache::flush_dependents_on(instanceKlassHandle)+0x6a V [libjvm.so+0x1fff88f] void SystemDictionary::add_to_hierarchy(instanceKlassHandle,Thread*)+0x6f V [libjvm.so+0x1ffc070] Klass*SystemDictionary::parse_stream(Symbol*,Handle,Handle,ClassFileStream*,const Klass*,GrowableArray<Handle>*,Thread*)+0x390 V [libjvm.so+0x20a11fc] instanceKlassHandle Unsafe_DefineAnonymousClass_impl(JNIEnv_*,_jclass*,_jbyteArray*,_jobjectArray*,unsigned char**,Thread*)+0x84c V [libjvm.so+0x20a179c] Unsafe_DefineAnonymousClass0+0x1fc J 1952 java.base@9-internal9-internal (0 bytes) @ 0xffff80ff982f3f31 [0xffff80ff982f3dc0+0x0000000000000171] J 2046 C1 java.base@9-internal9-internal (103 bytes) @ 0xffff80ff91432924 [0xffff80ff91432240+0x00000000000006e4] J 2097 C1 java.base@9-internal9-internal (106 bytes) @ 0xffff80ff9146de74 [0xffff80ff9146dde0+0x0000000000000094] J 2048 C2 java.base@9-internal9-internal (37 bytes) @ 0xffff80ff982fe294 [0xffff80ff982fdf40+0x0000000000000354] J 2096 C1 java.base@9-internal9-internal (32 bytes) @ 0xffff80ff9146d88c [0xffff80ff9146d820+0x000000000000006c] J 2893 C2 java.base@9-internal9-internal (84 bytes) @ 0xffff80ff983809e4 [0xffff80ff983809a0+0x0000000000000044] j java.lang.invoke.BoundMethodHandle$Species_L13.make(Ljava/lang/invoke/MethodType;Ljava/lang/invoke/LambdaForm;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;\ Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/invoke/BoundMethodHandle; [error occurred during error reporting (printing native stack), id 0xb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J 1952 java.base@9-internal9-internal (0 bytes) @ 0xffff80ff982f3ebb [0xffff80ff982f3dc0+0x00000000000000fb] [error occurred during error reporting (printing Java stack), id 0xb] ... It seems that walking the stack was not possible (neither for Forte, nor for the VM error reporting). More investigation is necessary to determine if the problem is due to these changes or exists otherwise as well.
31-03-2016