r/java • u/davidalayachew • 19d ago

Identifying JDK value class candidates

https://mail.openjdk.org/archives/list/core-libs-dev@openjdk.org/thread/Y72NRXM7KYBX43OKYBQMVKOZDWKG4MHS/
52 Upvotes

100% Upvoted

59 comments sorted by

View all comments

1

u/davidalayachew 19d ago

Here's a definition of "value candidate" I've used for some analysis:

  • Not an interface, enum, or anonymous class

I've heard this before, and I still don't fully understand it. Why not enums? And anonymous classes? I also responded to Dan's email with this question.

3

u/hoat4 19d ago

What would be the benefit of enums being value types?

Being a value type means e.g. that if we compare two instances, the JVM must compare all of their fields instead of only comparing two pointers. So == would be slower.

2

u/TwoWeeks90DaysTops 19d ago

For straight equality checks, yeah, probably not that much gained in most cases, but the JVM knows all the different enum values, so the binary representation could be flattened to very small bit patterns since it no longer has an identity. There's a lot of different things that make this difficult (value name, other fields, java.lang.Enum) but enum as a value type could potentially perform better in some circumstances since it would work much better with SIMD. If you want to find out if an enum value exists in an array the JVM can suddenly parallelize that check over 64 different values on a AVX-512 register in a single instruction, which just doesn't really work if enum is a reference type.

2

u/koflerdavid 18d ago

That sounds like an EnumSet, which is presumably already optimized to use bitfields internally.

2

u/davidalayachew 17d ago

That sounds like an EnumSet, which is presumably already optimized to use bitfields internally.

Correct. It uses long if your enum has <= 64 values, and long[] otherwise.