perf: continue eval STRING optimization work (follow-up to #1940)

未关闭
#1,961 1 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
52/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
java, perl

调研方向

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.java
  • src/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.java
  • src/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/442ce8c09 eval-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 skips synchronized lifecycleMonitor but still pushes a BindingFrame; the LIFO invariant in PerlRuntimeTest must stay green.
主要语言
Perl
星标
65
派生
8
平均合并
5 小时 45 分钟
30 天内合并 PR
184

环境准备

  • 提供 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 摘要。