包生态系统使用的诊断

SnoopCompile在Julia的编译器上"窥探"，以提取有关无效和类型推断的分析信息。 它有几个内部用于不同的目的:

*记录失效: 基地。静态数据。debug_method_invalidation 和 ccall(:jl_debug_method_invalidation,...)：这些记录了不同的无效模式。 SnoopCompile的用户将在加载包时暂时打开这些功能。 每个都会产生一个标准的日志格式;搞乱日志格式可能需要对SnoopCompile进行补充拉取请求。 SnoopCompile将处理这些日志，并生成可归因于方法表或绑定中的特定更改的无效CodeInstances树。 *观察推理: ccall(:jl_set_newly_inferred,...) 和 ccall(:jl_set_inference_entrance_backtraces,...)：这些用于理解推理是如何触发的。 主要目的是让性能诊断了解TTFX的来源。 其中的第二个 ccalls在类型推断的每个入口上记录一个回溯，以便SnoopCompile可以确定动态调度调用的调用者。 这是为新类型推断属性"原因"所必需的。 该 jl_set_inference_entrance_backtraces 函数接受一个数组，其中推理入口事件将被记录。 每个推理事件存储两个连续的数组元素：第一个 [医]代码 对象，然后是回溯表示。 所以对于N个推理事件，数组将包含2n个元素，排列为: [ci₁,bt₁,ci₂,bt₂,...,ciₙ,btₙ]. 请注意，backtrace元素 btᵢ 包含通常需要使用以下方法处理的原始回溯数据 stacktrace（基地。_reformat_bt(btᵢ...)). 将它们转换为可用的堆栈跟踪格式进行分析.