perf: continue eval STRING optimization work (follow-up to #1940)
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 52/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 领域
- backend, performance
调研方向
Start with src/main/java/org/perlonjava/frontend/parser/Parser.java and the listed allocation hotspots; run dev/bench/benchmark_eval_string.pl to establish a baseline. The issue lists five possible optimizations across parser, emitter, lexer, runtime, and symbol table, so pick one and measure its impact. Run nice -n 19 make and verify both backends with the provided eval commands; done means the change passes and improves the benchmark without breaking those checks.
由索引模型根据 Issue 内容生成。
描述
Context
PR #1940 reduced eval STRING overhead from 6.8× to 6.0× slower than system Perl on dev/bench/benchmark_eval_string.pl:
| ops/sec | |
|---|---|
| System Perl | 263,000/s |
| PerlOnJava (post-PR #1940) | 43,700/s |
| Ratio | 6.0× |
All optimizations in PR #1940 targeted the real pipeline per unique eval string (no eval-string caching). The remaining gap is structural — JVM overhead vs native C.
Remaining opportunities (in estimated impact order)
1. Lazy indexSourceLines() in Parser — high impact
File: src/main/java/org/perlonjava/frontend/parser/Parser.java (~lines 383–394)
indexSourceLines() is called from both constructors and scans the entire token list to build a line-number index array. For eval strings, no source-line lookup is needed at runtime unless an exception is thrown.
Fix: Remove the call from both constructors. Build the int[] lazily on the first sourceLineAt() call (add a boolean lineIndexBuilt field, or check lineIndex == null).
Evidence: This was the #1 allocation hotspot in a JFR profile of 500k iterations (416 samples). Saving one int[] allocation + O(tokens) scan per eval.
2. Lazy EmitterContext.contextCache and JavaClassInfo maps — medium impact
Files:
src/main/java/org/perlonjava/backend/jvm/EmitterContext.javasrc/main/java/org/perlonjava/backend/jvm/JavaClassInfo.java
EmitterContext.contextCache is a HashMap allocated eagerly in the constructor even for evals that never write to it.
JavaClassInfo has 4 pin/literal maps allocated eagerly.
Fix: Initialize each to null; create on first write via a private accessor. Readers check for null (return empty or no-op).
Savings: 5 map allocations per eval.
3. Lexer sawBegin flag to skip BEGIN aliasing loop — medium impact
Files:
src/main/java/org/perlonjava/frontend/lexer/Lexer.javasrc/main/java/org/perlonjava/runtime/runtimetypes/RuntimeCode.java
evalStringWithInterpreter() (RuntimeCode.java around line 5330) iterates ALL visible variables on every eval to support BEGIN {} inside eval strings. BEGIN in eval is extremely rare.
Fix: Add boolean sawBegin to Lexer. In nextToken(), when creating an IDENTIFIER token, check if text.equals("BEGIN") and set sawBegin = true. After tokenize(), evalStringWithInterpreter() checks lexer.sawBegin — if false, skip the entire alias loop.
Savings: O(visible_vars) String allocations + HashMap lookups eliminated on the common path.
4. Skip BitSet.clone() for empty BitSets in enterScope — low impact
File: src/main/java/org/perlonjava/frontend/semantic/ScopedSymbolTable.java
enterScope() unconditionally clones 3 BitSets even when they are empty (the common case for eval strings with no warning pragmas).
Fix: Replace existing.clone() with new BitSet() when existing.isEmpty().
5. Pool common LexerToken instances — low impact
File: src/main/java/org/perlonjava/frontend/lexer/Lexer.java
NEWLINE and common single-char operator tokens (,, ;, (, ), {, }) are allocated fresh on every tokenization. These are stateless value objects.
Fix: Static flyweight instances; return pooled instance from nextToken() for these common cases.
Measurement guidance
Benchmark command:
# Warm up JVM + measure
timeout 120 ./jperl dev/bench/benchmark_eval_string.pl
# System Perl baseline
perl dev/bench/benchmark_eval_string.pl
# Quick smoke (no JVM warmup noise):
timeout 30 ./jperl -e 'use Benchmark qw(timethis); timethis(500_000, sub { eval "1" })'
For each change, run nice -n 19 make first (full test suite). Both backends must still pass:
./jperl -e 'eval "my \$x = 1"'
./jperl --interpreter -e 'eval "my \$x = 1"'
Profile guidance
The JFR profile that informed PR #1940 used:
./jperl -XX:+UnlockDiagnosticVMOptions -XX:StartFlightRecording=... -e '
for (1..500_000) { eval "my \$x = 1 + 2; \$x" }
'
A fresh profile after PR #1940 merges will show whether the allocation hotspot has shifted.
Notes
- The
a59926c1a/442ce8c09eval-string cache experiment was tried and removed — it caused correctness issues and the cache key was too coarse. Do not re-add a simple string-equality cache for eval. - The
PerlRuntime.bind()re-entrant fast-path skipssynchronized lifecycleMonitorbut still pushes aBindingFrame; the LIFO invariant inPerlRuntimeTestmust stay green.
- 主要语言
- Perl
- 星标
- 65
- 派生
- 8
- 平均合并
- 5 小时 45 分钟
- 30 天内合并 PR
- 184
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
fglock/PerlOnJava 的其他 Issue
-
area:runtime documentation enhancement
难度 2/5 1-3 小时 新手友好度 72/100
fglock/PerlOnJava#1579 ·
维护者通常 1 天内回复
-
area:backend bug
难度 4/5 3-5 天 新手友好度 55/100
fglock/PerlOnJava#1981 · 1 条评论 ·
维护者通常 1 天内回复
-
area:runtime bug
难度 4/5 3-5 天 新手友好度 57/100
fglock/PerlOnJava#1980 · 1 条评论 ·
维护者通常 1 天内回复
-
area:parser bug
难度 4/5 3-5 天 新手友好度 48/100
fglock/PerlOnJava#1979 · 1 条评论 ·
维护者通常 1 天内回复
-
area:cpan-port bug
难度 5/5 一周以上 新手友好度 35/100
fglock/PerlOnJava#1962 ·
维护者通常 1 天内回复
查看 fglock/PerlOnJava 的全部 Issue
相似的 Issue
-
ai-driven-fuzzing bug claude Minor
难度 2/5 1-3 小时 新手友好度 72/100
linagora/lemonldap-ng-plugins#170 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
libwww-perl/HTTP-Message#236 ·
-
1.severity: security
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 2 天内回复
-
wave-followup
难度 2/5 1-3 小时 新手友好度 74/100