[yanghang8612]

What does this PR do?

Optimize each cached JUMPDEST analysis by storing positions in a bitmap instead of a HashSet of program counters. The scan is unchanged: a JUMPDEST opcode is recorded, and the immediate bytes of PUSH1 through PUSH32 are still skipped. A program counter outside the code returns false.

The cache key, the entry cap, and energy charging stay the same. A constant call still compiles on the frame and is not inserted into the cache.

Why are these changes required?

Each cached analysis kept one boxed integer per JUMPDEST. The bitmap records the same positions and substantially reduces the space occupied by the cache.

This PR has been tested by:

• Unit Tests

JumpDestBitmapTest checks the bitmap against the previous scan, including PUSH immediate data, a single destination among other bytes, and random code.

Follow up

A failed CREATE analysis is still inserted into the cache. This change does not remove those entries.

Extra details

A finished analysis reports the same JUMPDEST positions as before, so this does not require a proposal gate.

[alan-eth]

The bitmap is a compact way to preserve the existing JUMPDEST lookup behavior. Would it be worth adding lightweight cache hit/miss counters in Program.getProgramPrecompile() to help assess cache effectiveness under real workloads? We could count only actual shared-cache lookups, keeping constant calls separate since they bypass the LRU. This could also be a follow-up to keep this optimization focused.