hs_err_pid.log中的"Events"是什么？
What are "Events" in hs_err_pid.log?
我在 hs_err_pid.log 中找到了这些。
Events (10 events):
Event: 2603309.010 Thread 0x00007ff2c800c000 DEOPT UNPACKING pc=0x00007ff34aaddf69 sp=0x00007ff3409e88a8 mode 2
Event: 2603310.108 Thread 0x00007ff362229000 DEOPT PACKING pc=0x00007ff34b25ce6c sp=0x00007ff340ceb660
Event: 2603310.122 Thread 0x00007ff2c8009800 Uncommon trap: trap_request=0xffffff65 fr.pc=0x00007ff34b890e40
Event: 2603310.124 Thread 0x00007ff2c8009800 DEOPT PACKING pc=0x00007ff34b890e40 sp=0x00007ff3408e7790
Event: 2603310.124 Thread 0x00007ff2c8009800 DEOPT UNPACKING pc=0x00007ff34aaddf69 sp=0x00007ff3408e7680 mode 2
Event: 2603310.125 Thread 0x00007ff2c8009800 Uncommon trap: trap_request=0xffffff65 fr.pc=0x00007ff34b850fe4
Event: 2603310.125 Thread 0x00007ff2c8009800 DEOPT PACKING pc=0x00007ff34b850fe4 sp=0x00007ff3408e7560
Event: 2603310.125 Thread 0x00007ff2c8009800 DEOPT UNPACKING pc=0x00007ff34aaddf69 sp=0x00007ff3408e72d8 mode 2
Event: 2603310.126 Thread 0x00007ff362229000 DEOPT UNPACKING pc=0x00007ff34aaddf69 sp=0x00007ff340ceb628 mode 2
Event: 2603310.935 Thread 0x00007ff2d8001000 Thread added: 0x00007ff2d8001000
我不知道这些信息，我很好奇，尽管它可能无法帮助我分析崩溃。
- 像“2603309.010”这样的数字是什么意思？
- 描述是什么意思？包括 DEOPT、UNPACKING/PACKING、罕见陷阱、trap_request、pc 和 sp ?
这是最近 10 个 VM 运行时事件的历史记录（编译和 GC 除外）。
2603309.010 是时间戳 - 自 VM 启动以来的秒数。
Uncommon trap 是编译代码中推测性前提条件失败的情况。它通常会导致 deoptimization - 从编译代码切换回解释器。去优化首先收集有关虚拟帧的信息（打包），然后将这些帧以解释器格式展开到堆栈中（解包）。 pc和sp是程序计数器和堆栈指针。
uncommon trap
When code generated by C2 reverts back to the
interpreter for further execution. C2 typically compiles for the
common case, allowing it to focus on optimization of frequently
executed paths. For example, C2 inserts an uncommon trap in generated
code when a class that is uninitialized at compile time requires run
time initialization.
deoptimization
The process of converting an compiled (or more
optimized) stack frame into an interpreted (or less optimized) stack
frame. Also describes the discarding of an nmethod whose dependencies
(or other assumptions) have been broken. Deoptimized nmethods are
typically recompiled to adapt to changing application behavior.
Example: A compiler initially assumes a reference value is never null,
and tests for it using a trapping memory access. Later on, the
application uses null values, and the method is deoptimized and
recompiled to use an explicit test-and-branch idiom to detect such
nulls.
我在 hs_err_pid.log 中找到了这些。
Events (10 events):
Event: 2603309.010 Thread 0x00007ff2c800c000 DEOPT UNPACKING pc=0x00007ff34aaddf69 sp=0x00007ff3409e88a8 mode 2
Event: 2603310.108 Thread 0x00007ff362229000 DEOPT PACKING pc=0x00007ff34b25ce6c sp=0x00007ff340ceb660
Event: 2603310.122 Thread 0x00007ff2c8009800 Uncommon trap: trap_request=0xffffff65 fr.pc=0x00007ff34b890e40
Event: 2603310.124 Thread 0x00007ff2c8009800 DEOPT PACKING pc=0x00007ff34b890e40 sp=0x00007ff3408e7790
Event: 2603310.124 Thread 0x00007ff2c8009800 DEOPT UNPACKING pc=0x00007ff34aaddf69 sp=0x00007ff3408e7680 mode 2
Event: 2603310.125 Thread 0x00007ff2c8009800 Uncommon trap: trap_request=0xffffff65 fr.pc=0x00007ff34b850fe4
Event: 2603310.125 Thread 0x00007ff2c8009800 DEOPT PACKING pc=0x00007ff34b850fe4 sp=0x00007ff3408e7560
Event: 2603310.125 Thread 0x00007ff2c8009800 DEOPT UNPACKING pc=0x00007ff34aaddf69 sp=0x00007ff3408e72d8 mode 2
Event: 2603310.126 Thread 0x00007ff362229000 DEOPT UNPACKING pc=0x00007ff34aaddf69 sp=0x00007ff340ceb628 mode 2
Event: 2603310.935 Thread 0x00007ff2d8001000 Thread added: 0x00007ff2d8001000
我不知道这些信息，我很好奇，尽管它可能无法帮助我分析崩溃。
- 像“2603309.010”这样的数字是什么意思？
- 描述是什么意思？包括 DEOPT、UNPACKING/PACKING、罕见陷阱、trap_request、pc 和 sp ?
这是最近 10 个 VM 运行时事件的历史记录（编译和 GC 除外）。
2603309.010 是时间戳 - 自 VM 启动以来的秒数。
Uncommon trap 是编译代码中推测性前提条件失败的情况。它通常会导致 deoptimization - 从编译代码切换回解释器。去优化首先收集有关虚拟帧的信息（打包），然后将这些帧以解释器格式展开到堆栈中（解包）。 pc和sp是程序计数器和堆栈指针。
uncommon trap
When code generated by C2 reverts back to the interpreter for further execution. C2 typically compiles for the common case, allowing it to focus on optimization of frequently executed paths. For example, C2 inserts an uncommon trap in generated code when a class that is uninitialized at compile time requires run time initialization.
deoptimization
The process of converting an compiled (or more optimized) stack frame into an interpreted (or less optimized) stack frame. Also describes the discarding of an nmethod whose dependencies (or other assumptions) have been broken. Deoptimized nmethods are typically recompiled to adapt to changing application behavior. Example: A compiler initially assumes a reference value is never null, and tests for it using a trapping memory access. Later on, the application uses null values, and the method is deoptimized and recompiled to use an explicit test-and-branch idiom to detect such nulls.