RFR: JDK-8219412: Eager enum class initialization with enum switch
Jan Lahoda
jan.lahoda at oracle.com
Fri Apr 5 11:58:22 UTC 2019
On 4.4.2019 20:50, Brian Goetz wrote:
> Note that when we switch to translating with indy, this can be cached at
> the indy call site. (And, in the case where the compile-time and
> run-time numberings are the same, we can even, if we like, eliminate the
> indirection through the array.)
Yes, with the indy desugaring this all goes away. But I suspect it will
probably take some time before we switch to that, so seemed prudent to
fix using the approach we currently have.
Jan
>
> On 4/4/2019 1:59 PM, Jan Lahoda 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
>
More information about the compiler-dev
mailing list