RFR: JDK-8241798: Allow enums to have more constants

[Liam Miller-Cushon]

Please consider this change to allow enums to have ~4100 constants (up from
the current limit of ~2740), by moving the creation of the values array out
of the clinit to a helper method.

It's fair to ask whether this is worth doing. Increasing the limit by this
amount doesn't really change the use-cases enums are suitable for: they
still can't represent arbitrarily large collections of constants, and if
you have an enum with >2740 constants you're probably going to want >4100
eventually. On the other hand, I don't see any obvious drawbacks to the
change (in terms of complexity in the compiler, performance impact, or
complexity of generated code). And other options for increasing the limit
would require significantly more difficult and longer-term changes (e.g.
tackling the method and constant pool size limits).

Another question is whether this is the best code generation strategy.
Currently javac saves the values array to a field and returns copies of it
using clone(). The approach ecj uses skips the field, and just re-creates
the array every time values() is called. For now I'm keeping the values
field to minimize the performance impact of this change, but the ecj
approach would avoid that field and the helper method.

bug: https://bugs.openjdk.java.net/browse/JDK-8241798
webrev: http://cr.openjdk.java.net/~cushon/8241798/webrev.00/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200328/7fa3d28f/attachment.htm>