<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
but isn't it the case that bootstrap methods can have up to 255
arguments due to the limits on method descriptors?<br>
<br>
Vicente<br>
<br>
<div class="moz-cite-prefix">On 3/28/20 8:12 PM, Remi Forax wrote:<br>
</div>
<blockquote type="cite"
cite="mid:1231523245.1761154.1585440744725.JavaMail.zimbra@u-pem.fr">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div style="font-family: arial, helvetica, sans-serif; font-size:
12pt; color: #000000">
<div>Hi Liam,<br data-mce-bogus="1">
</div>
<div>Having values() initialized is the static block is a common
issue once you have a code generator that spit enums.<br
data-mce-bogus="1">
</div>
<div>I had a similar issue and ends up not using enums but plain
old classes in the generator because of that.<br>
</div>
<div><br data-mce-bogus="1">
</div>
<div>There is another solution,<br data-mce-bogus="1">
</div>
<div>you can use constantdynamic and pass the names of the
constants (an array) as a bootstrap argument,</div>
<div>you can go up to 65 635 (the limit in term of number of
fields), in fact far less because the constant pool will be
full before that point.<br data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>
<div>public static MyEnum[] values() {</div>
<div> ldc "values" [MyEnum
[BSM=java/lang/runtime/ConstantEnumMetaFactory]
["constant1", "constant2", ...]<br>
</div>
<div> invokevirtual clone()</div>
<div> areturn<br data-mce-bogus="1">
</div>
<div>}</div>
</div>
<div><br data-mce-bogus="1">
</div>
<div>The major advantage of using constant dynamic is that if
nobody calls the method values(), the array is never
initialized.</div>
<div><br data-mce-bogus="1">
</div>
<div>And once the VM will suport fields declared as "lazy static
final", you can get ride of the static bock because the
initialization of the constant fields will be done lazily too.<br
data-mce-bogus="1">
</div>
<div><br data-mce-bogus="1">
</div>
<div>Rémi<br data-mce-bogus="1">
</div>
<div><br>
</div>
<hr id="zwchr" data-marker="__DIVIDER__">
<div data-marker="__HEADERS__">
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>De:
</b>"Liam Miller-Cushon" <a class="moz-txt-link-rfc2396E" href="mailto:cushon@google.com"><cushon@google.com></a><br>
<b>À: </b>"compiler-dev"
<a class="moz-txt-link-rfc2396E" href="mailto:compiler-dev@openjdk.java.net"><compiler-dev@openjdk.java.net></a><br>
<b>Envoyé: </b>Dimanche 29 Mars 2020 00:37:24<br>
<b>Objet: </b>RFR: JDK-8241798: Allow enums to have more
constants<br>
</blockquote>
</div>
<div data-marker="__QUOTED_TEXT__">
<blockquote style="border-left:2px solid
#1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">
<div dir="ltr">
<div>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.</div>
<br>
<div>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).</div>
<br>
<div>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.</div>
<br>
bug: <a
href="https://bugs.openjdk.java.net/browse/JDK-8241798"
target="_blank" moz-do-not-send="true">https://bugs.openjdk.java.net/browse/JDK-8241798</a>
<div>webrev: <a
href="http://cr.openjdk.java.net/~cushon/8241798/webrev.00/"
target="_blank" moz-do-not-send="true">http://cr.openjdk.java.net/~cushon/8241798/webrev.00/</a><br
data-mce-bogus="1">
</div>
</div>
<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>