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

[Jan Lahoda]

Hi Liam,

On 4.4.2019 20:20, Liam Miller-Cushon wrote:
> 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-8169526

Yes, those should be hopefully fixed as well.

>
> 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).

For OpenJDK, there are ~150 additional classes (from 30267 to 30415).

>
> 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.

I didn't really want to change the balances in the desugaring except as 
really necessary. The current desugaring shares the mapping for any 
given enum across the whole top-level class, which cannot (I think) be 
easily achieved when the field is in the actual class that uses it. This 
is particularly because of the foreseen change to indy desugaring.

Jan

>
> On Thu, Apr 4, 2019 at 11:04 AM Jan Lahoda <jan.lahoda at oracle.com
> <mailto: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/
>     JBS: https://bugs.openjdk.java.net/browse/JDK-8219412
>
>     How does this look?
>
>     Thanks,
>           Jan
>