<div dir="ltr"><div>Hi Liam,</div><div><br></div><div>I don't have any strong opinions but would like to point out that this change may also impact <a href="https://bugs.openjdk.org/browse/JDK-8219412">JDK-8219412</a> (probably in a good way).<br></div><div><br></div><div>See also this relevant discussion: <a href="https://mail.openjdk.org/pipermail/compiler-dev/2023-January/021662.html">https://mail.openjdk.org/pipermail/compiler-dev/2023-January/021662.html</a> <br></div><br><div>-Archie<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 9, 2023 at 4:46 PM Liam Miller-Cushon <<a href="mailto:cushon@google.com">cushon@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello,<br><br>I'd like to discuss the idea of using constant dynamic in the generated code for enums.<br><br>The possibility of using condy came up in the review thread for JDK-8241798, which implemented a small change to the code generation strategy for enums to raise the limit on the number of enum constants. To recap, there are limits on the number of constants in an enum imposed by the class file format. The constants are represented as static final fields, which have to be initialized in the clinit, which eventually runs into the 64k method size limit:<br><br><a href="https://mail.openjdk.org/pipermail/compiler-dev/2020-March/014413.html" target="_blank">https://mail.openjdk.org/pipermail/compiler-dev/2020-March/014413.html</a><br><a href="https://bugs.openjdk.org/browse/JDK-8241798" target="_blank">https://bugs.openjdk.org/browse/JDK-8241798</a><br><br>I did some recent experimentation into using condy to initialize enum constants and create the values array. There's a very rough draft here: <a href="https://github.com/openjdk/jdk/pull/16108" target="_blank">https://github.com/openjdk/jdk/pull/16108</a><br><br>With that change the clinit just contains a ldc/putstatus for each constant, which is 6 bytes per constant, raising the limit on the number of constants from ~4k today to about 10k.<br><br>I am interested in high level feedback about the idea. Does this seem like a good use of condy, or a bad use of condy? Are there reasons (performance, maintenance, other things I'm not considering) why using condy in this way wouldn't be advisable?<br><br>One caveat is that it may not be very valuable to raise the limit further. Four thousand is already a lot of enum constants. I suspect for many domains where it's necessary to represent >4k values, it will eventually need to represent >10k values, and that enums are not the best way to model those domains. So I wouldn't argue for doing this if there end up being a lot of trade-offs, but if the condy approach was appealing in general perhaps raising the limit at the same time could be win-win.<br><br>Working through the prototype raised some questions about what a production quality implementation would look like:<br><br>Enums with user-defined constructors are currently only handled if the arguments are static constants. What would the right solution be? Perhaps a factory method could be synthetized for constants with non-constant arguments, so condy could still be used to load them.<br><br>The class initializer for MethodHandle transitively loads enums, so having enum class initializers use condy creates a cyclic dependency. The prototype skips the new strategy for java.base. I could imagine having a way to opt specific enums out of the new strategy, but having to maintain multiple code generation strategies for enums does not seem very appealing. Perhaps there's a way to refactor to break those cycles, or that the lazy static final field proposal in JDK-8209964 could help here, or something else.<br><br>I'm curious what you think,<br>Liam<br></div>
</blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div>