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

[Liam Miller-Cushon]

Deferring the code golf approach makes sense to me, thanks. It might be an
interesting option for code generators that are running into this limit,
and that are willing to generate bytecode directly instead of source.

I did some benchmarking of the original patch, and found that the
difference is within measurement error and that the assembly appears to be
identical, as expected. The benchmark is just looking at steady-state calls
to values(), I'm not sure what the best way to measure the effect of the
additional method call in the clinit would be. The code is here:
http://cr.openjdk.java.net/~cushon/benchmark/JDK-8241798/

Remy, you pointed out that this could make it harder for AOT compilers to
find the value of the constants without executing the clinit. Do you have
suggestions for quantifying that risk? I tried running a demo through
GraalVM/native-image for fun and it didn't seem to cause any problems.

Also, I fixed up the unnecessary `final` modifier in the synthetic values
methods, and uploaded a new webrev:
http://cr.openjdk.java.net/~cushon/8241798/webrev.01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200331/0e078836/attachment.htm>