RFR: JDK-8219412: Eager enum class initialization with enum switch

[Remi Forax]

Hi Jan, 
it seems like a perfect case for a constant dynamic, 
the array can be loaded using ldc and the bootstrap method takes the enum names as constant arguments. 

You doesn't have to create one class per switch, it's lazy initialized like any constant pool item and each switch on the same enum type can reuse the same, 
compare to the solution implemented by Eclipse, it's not a field but a constant pool constant you you can not mess with it using reflection and you don't need to check if the array was loaded or not in the fastpath. 

regards, 
Rémi 

> De: "Liam Miller-Cushon" <cushon at google.com>
> À: "jan lahoda" <jan.lahoda at oracle.com>
> Cc: "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoyé: Jeudi 4 Avril 2019 20:20:00
> Objet: Re: RFR: JDK-8219412: Eager enum class initialization with enum switch

> Hi Jan,
> There are a couple of other bugs about enum switch / class initialization issues
> that I think are addressed by this approach:
> [ https://bugs.openjdk.java.net/browse/JDK-7176515 |
> https://bugs.openjdk.java.net/browse/JDK-7176515 ]
> [ https://bugs.openjdk.java.net/browse/JDK-8169526 |
> https://bugs.openjdk.java.net/browse/JDK-8169526 ]

> Do you have a sense of how many additional auxiliary classes this will create
> for typical applications? I'm wondering if the number of additional classes
> might be large enough to effect performance (i.e. binary size, classloading).

> Were other lazy initialization patterns considered? JDK-7176515 mentions that
> ecj avoids this by caching the switch map in a field in the same class as the
> switch.

> On Thu, Apr 4, 2019 at 11:04 AM Jan Lahoda < [ mailto:jan.lahoda at oracle.com |
> jan.lahoda at oracle.com ] > wrote:

>> Hi,

>> When there is a switch over enum in the code, and is compiled into the
>> bytecode, the meaning of the switch should not change even if the enum's
>> constant are reordered. This is achieved by a map that maps the
>> (current) enum constants to the appropriate case in the switch. This map
>> is stored in a field in an auxiliary class, and filled when that
>> auxiliary class is loaded in.

>> But, if there are multiple switches over distinct enums under a single
>> top-level class, the mapping fields for all the enums are stored in a
>> single class. So, when any of these is needed, the mapping is
>> constructed for all the enums, which may cause enum class initialization
>> even in cases where it shouldn't happen.

>> The proposed fix is to create a separate auxiliary classes for each
>> enum/mapping.

>> Proposed patch: [ http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ |
>> http://cr.openjdk.java.net/~jlahoda/8219412/webrev.00/ ]
>> JBS: [ https://bugs.openjdk.java.net/browse/JDK-8219412 |
>> https://bugs.openjdk.java.net/browse/JDK-8219412 ]

>> How does this look?

>> Thanks,
>> Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190404/c6ae1af3/attachment.html>