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

[Liam Miller-Cushon]

To preface this, I'm also interested in the options involving condy, but
even if that ends up being the preferred strategy for a future language
version I think there's value in increasing the limit for existing language
versions (assuming we can find a way to do that with acceptable complexity
and performance). It'll take time before some of the code generators
affected by the current limit can target Java 16+ features.

On Mon, Mar 30, 2020 at 11:10 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> Liam, what's the constraint that brings you down to 4100?
>

At some point we start needing ldc_w and sipush for the names and ordinals,
which makes it 16 bytes per constant.


> However, we can probably squeeze a little more out by another refactoring,
> which would be to initialize the values method _first_ and then initialize
> the fields from that
>

Thanks! It looks like that gets us down to 8 bytes per constant in the
clinit, or ~8200 constants total. Initializing the values() array now takes
18 bytes per constant, but that part is easy to split across multiple
helper methods.

I have a prototype that mostly works (*) and handles 8207 constants. I'll
clean that up tomorrow, and do some benchmarking with both approaches to
better understand any performance trade-offs / cliffs, and will report back.

(*) the caveat is that enum constants can refer to other constants in their
initializers, e.g.:

enum T {
  ONE,
  TWO(ONE);

  final T t;

  T(T t) { this.t = t; }
  T() { this(null); }
}

It's possible to fix some cases by fixing up references to use the values
array (e.g. `new T("TWO", 1, values[0]);`), but that doesn't work in
general.

I think that limits this strategy to enums that don't declare constructors
with non-mandated parameters. I'd still be happy to have support for that
many constants in 'simple' enums, but needing different code generation
strategies for different kinds of enum does change the return-on-complexity
a bit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20200330/b35ca05b/attachment.htm>