Avoid repeated reachability walks while Moose modules initialize

未关闭
  • 哪里不对？
#1,950 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
35/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
活跃
技术栈
java
领域
compilers

调研方向

Start in WeakRefRegistry.weaken(), at the weakenedLiveBlessedRef condition, where reachableOwnerCount() is evaluated before ModuleInitGuard.inModuleInit(). Follow reachableOwnerCount() into ReachabilityWalker.isScalarReachable() to see the root walk. Reorder the check, add a deterministic regression test for module initialization, and confirm weak-reference behaviour outside module init. Done when t/05_round.t finishes on both the JVM and interpreter backends.

由索引模型根据 Issue 内容生成。

描述

area:memory area:performance bug

Summary

Loading StorageDisplay 1.0.11 through Moose triggers a large number of Scalar::Util::weaken calls. For live blessed references, WeakRefRegistry.weaken() calls reachableOwnerCount(), which repeatedly walks the Perl object graph. The module-initialization guard is checked only after this expensive query, so it does not suppress the work during module loading. The repeated walks make t/05_round.t exceed the CPAN tester timeout on both PerlOnJava backends.

Evidence

  • CPAN random tester run: 20261102-094403-98885
  • Distribution: StorageDisplay-1.0.11; failing test: t/05_round.t
  • System Perl 5.42.2: full suite passed, 7 files / 85 tests, in about 6 seconds.
  • PerlOnJava 5.44.1 / Java 24.0.2: CPAN run timed out after 120 seconds with no output for 60 seconds. Focused runs of t/05_round.t with the archived dependency overlay exceeded a 40-second hard timeout on both JVM and interpreter backends.
  • An 8-second JVM Flight Recorder profile of use StorageDisplay showed repeated stacks through ScalarUtil.weaken, RuntimeBase.reachableOwnerCount, and ReachabilityWalker root traversal. This is repeated work, not evidence of an infinite loop.

StorageDisplay is pure Perl and uses Moose 2.4000 and namespace::sweep 0.006. The PerlOnJava report showed t/000-report-versions.t passing before the harness stopped producing output.

Suspected cause

In WeakRefRegistry.weaken(), the condition at the weakenedLiveBlessedRef check evaluates base.reachableOwnerCount() == 0 before !ModuleInitGuard.inModuleInit(). reachableOwnerCount() checks each active owner using ReachabilityWalker.isScalarReachable(), which traverses the global root graph. Moose performs many such weaken operations while required modules execute under ModuleInitGuard, multiplying full root walks during initialization.

Move the module-init check ahead of the reachability query, then confirm the same behavior is preserved outside module initialization.

Acceptance criteria

  • Add deterministic regression coverage proving module initialization does not perform the expensive reachable-owner walk for this path.
  • Run new/changed Perl-level coverage with system Perl first.
  • t/05_round.t completes under PerlOnJava's JVM and interpreter backends with the archived dependency load order.
  • Run the required build and lifecycle tests; retain bounded output and verify weak-reference semantics outside module initialization.

Related: #1642 and merged PR #1746 addressed other repeated reachability paths during cleanup. This CPAN case reproduces through WeakRefRegistry.weaken() during module initialization.

主要语言
Perl
星标
65
派生
8
平均合并
5 小时 52 分钟
30 天内合并 PR
175

环境准备

  • 提供 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

fglock/PerlOnJava 的其他 Issue

查看 fglock/PerlOnJava 的全部 Issue

相似的 Issue

更多 Perl Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。