[mcculls]

What Does This Do

Build method descriptor boundaries directly in an int[], replacing the temporary BitSet and its flattening pass in MethodOutline.parseBoundaries().

• No allocation for parameterless methods.
• One exact array allocation for one-parameter methods.
• Direct allocation of the initial two-slot buffer when more boundaries are needed.
• Capacity doubles by parameter count, with exact sizing at the final boundary.
• A single scan with separate terminal and continuing paths, without duplicated parameter parsing.
• Existing short-circuit behavior for malformed descriptors is preserved.

Motivation

The current BitSet grows according to descriptor offsets, then copies those offsets into the array retained by the method outline. Direct array construction avoids that intermediate storage and conversion. Capacity follows parameter count rather than the length of class names in the descriptor.

Fresh measurements of this parser-only change against main, using the existing Spring Web 7.0.9 corpus (1,325 classes / 9,633 methods):

Workload	Revision	Mean time (µs/corpus pass)	Allocated bytes/corpus pass
First-use boundaries	Main (946470c)	407.296	769,680
First-use boundaries	Array parser (3c958d3)	279.114	580,928
Outlines + all boundaries	Main (946470c)	2361.341	3,824,705
Outlines + all boundaries	Array parser (3c958d3)	2289.352	3,635,953

First-use boundary parsing averages 31.47% less time and 24.52% less allocation. Outlining followed by parsing every method's boundaries averages 3.05% less time and 4.93% less allocation. Both workloads save 188,752 bytes per corpus pass. The timings describe this corpus and JVM; some confidence intervals overlap.

Additional Notes

Measurement setup

• JMH 1.36; Zulu OpenJDK 17.0.20.1; macOS ARM64; one thread; -Xms512m -Xmx512m; GC profiler.
• Main / array parser, then array parser / main. Each run uses three forks, three 1-second warmup iterations, and five 1-second measurement iterations: six forks per revision and workload overall.
• Each operation processes the entire corpus. The isolated workload creates fresh method outlines from preloaded descriptors and consumes both the outlines and their boundary arrays. The combined workload parses fresh class outlines and then requests every method's boundaries. These measure first use, not cache hits.
• The same benchmark harness, corpus, and JVM settings are used for both versions. ClassFile and FieldOutline remain at main in both. Annotation-interest filtering is not enabled for these workloads.
• Ordinary class outline parsing does not request boundaries; its behavior is unchanged. Applications may inspect boundaries for only a subset of methods.

Individual timings with JMH's reported 99.9% confidence intervals (µs/corpus pass):

Workload	Revision	First round	Reverse-order round
First-use boundaries	Main (946470c)	417.148 ± 23.526	397.444 ± 11.440
First-use boundaries	Array parser (3c958d3)	275.246 ± 5.315	282.983 ± 7.380
Outlines + all boundaries	Main (946470c)	2349.142 ± 13.994	2373.540 ± 20.299
Outlines + all boundaries	Array parser (3c958d3)	2280.126 ± 54.135	2298.578 ± 14.547

Validation

• All 164 class-match tests pass on Java 8, 11, 17, 21, and 25.
• Formatting and SpotBugs main/test checks pass.
• Both implementations agree with ASM on boundaries for 10,035 methods across the Spring Web and ASM test corpora.
• Arrays and exception types match for 252,819 truncated/full descriptor prefixes from the corpus.

Contributor Checklist

Jira ticket: not provided.