[External] : Re: [JEP Proposal] Constant-Time Enum Size Access (https://gist.github.com/TuranDev/9a20c773d8c698de918da54b2964bf65)

[Ron Pressler]

> On 19 Nov 2025, at 22:21, Turan Suleyman <turansuleyman at proton.me> wrote:
> 
> Thanks both for the feedback.
> 
> So to the problem. In low-latency (nanosecond sensitivity) or gc sensitive systems, it’s common for frameworks, dispatch loops, and state machines to query enum metadata on the critical path.
> Even small, repeated array allocations (from values()) show up as avoidable GC pressure and measurable CPU cost under load.
> 
> Examples I’ve seen in practice where this occurs include:
> - HFT / real-time systems using enums for event codes, message categories, FIX tags
> - protocol engines where enums represent message types
> - parsers/tokenizers using enums for token types
> - table-driven state machines that query enum sizes on each transition
> 

With what JDK version and which GCs have you observed such issues? The model where allocations of short-lived objects cause more GC work isn’t the full picture with newer GCs anymore. With old GCs, fewer allocations generally meant more GC work, but these days, fewer allocations can sometimes mean *more* GC work.

Also, what portion of the CPU profile or of the latency are we talking about? This is important to judge the impact of the work. After all, improving the efficiency of some operation by 10,000x would only have an impact of <0.1% if that’s the portion of the profile to begin with.


> On the suggested solution of:
> 
> enum MyEnum {
>   public static final List<MyEnum> VALUES = List.of(MyEnum.values());
> }
> 
> Yes, it’s possible to write (and myself and others already leverage such patterns or utils as workarounds) but they have to be manually added to every enum and cannot be relied on by frameworks or libraries.
> They’re workarounds for something the compiler knows statically.

What portion of enums are on the hot path where this has a significant impact? Also, why is the size operation in particular so common (as opposed to also looking at the values themselves)? 

The more we understand the problem, the better we could tailor a solution that would be maximally helpful. For example, it’s possible that the best solution isn’t in the design of enum at all, but in making sure that the JIT optimises away the allocation.

— Ron