perf: multi-field object inline array storage (2-8 fields)

[He-Pin]

Motivation

Most Jsonnet objects have fewer than 9 fields. Currently, every object (except single-field objects from PR #687) allocates a LinkedHashMap to store its field names and members. This is wasteful for small objects where a flat array lookup is both faster and more memory-efficient.

Key Design Decision

Extend the existing single-field optimization (#687) with a three-tier storage strategy:

Fields	Storage	Lookup
1	singleFieldKey / singleFieldMember	Direct comparison
2-8	inlineFieldKeys[] / inlineFieldMembers[]	Linear scan (fast for ≤8)
9+	LinkedHashMap (existing)	Hash lookup

The threshold of 8 was chosen because:

• Linear scan of 8 string references fits in a CPU cache line
• The vast majority of Jsonnet objects have ≤8 fields (config blocks, function params, etc.)
• Beyond 8, hash lookup amortizes the overhead of building the map

Modification

Val.scala

• Added inlineFieldKeys: Array[String] and inlineFieldMembers: Array[Val.Obj.Member] to Val.Obj constructor
• Updated all fast paths: getValue0, hasKeys, containsKey, containsVisibleKey, allKeyNames, visibleKeyNames, valueRaw
• All inline array returns use defensive .clone() to prevent caller mutation of internal state
• Lazy LinkedHashMap construction in getValue0 when needed (e.g., for addSuper)

Evaluator.scala

• Extracted shared trackField() helper for singleKey → inlineKeys → builder transitions
• Handles duplicate key detection at each tier
• Fixed getEmptyValueCacheForObjWithoutSuper(fieldCount) to use actual field count (not fields.length) — fixes over-allocation when computed field names resolve to null

Benchmark Results

JMH (JVM, single iteration, ms/op — lower is better)

Benchmark	Master	Multi-field	Change
bench.02	48.296	39.728	-17.7% ✅
bench.04	33.261	31.126	-6.4% ✅
realistic2	68.960	68.266	-1.0% ✅
comparison	23.093	22.501	-2.6% ✅
comparison2	72.498	67.287	-7.2% ✅
reverse	10.685	10.390	-2.8% ✅

All 35 benchmarks: zero regressions.

Native (Scala Native, hyperfine, ms — lower is better)

Benchmark	Master	Multi-field	Change	vs jrsonnet
realistic2	292.4ms	253.1ms	-13.4% ✅	1.84x faster
bench.02	68.5ms	68.2ms	~tied	N/A (jrsonnet hangs)
bench.04	533.7ms	535.0ms	~tied	~tied with jrsonnet

Analysis

The multi-field optimization primarily benefits workloads that create many small objects:

• bench.02 (recursive Fibonacci): Creates many 1-2 field objects → -17.7% on JVM
• comparison2: Array comparisons with object creation → -7.2% on JVM
• realistic2 (Kubernetes config): Mix of object sizes → -13.4% on native, 1.84x faster than jrsonnet
• bench.04 (deep recursion): Less object-creation-heavy → neutral

Native shows less benefit on bench.02 than JVM, suggesting the JVM JIT can better exploit the simplified object layout for inlining. The realistic2 native improvement (-13.4%) confirms the optimization helps real-world workloads.

References

• Upstream: jit branch commit 13e6ff39
• Builds on: PR perf: single-field object inline storage to avoid LinkedHashMap allocation #687 (single-field object optimization)

Result

All 140 tests pass. Zero benchmark regressions across 35 benchmarks. Significant improvements on object-heavy workloads, especially realistic2 where sjsonnet is now 1.84x faster than jrsonnet on native.