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

[Maurizio Cimadamore]

Thanks for running these tests, I agree this is a tad surprising.

The right way to address this, of course, would be to have a blessed JDK 
bootstrap method which works on any enum (in which case you don't even 
need the class?) - but I'm even more concerned about going in that 
direction for what is supposed to be an 'interim' fix.

Maurizio

On 09/04/2019 16:23, Jan Lahoda wrote:
> On 9.4.2019 13:58, Claes Redestad wrote:
>> Hi Jan,
>>
>> On 2019-04-09 12:32, Jan Lahoda wrote:
>>> For OpenJDK, there are ~150 additional classes (from 30267 to 30415)
>>> with the .00 version of the patch.
>>
>> to me it sounds those additional classes will mostly be the result of
>> splitting existing classes, so the static and potential runtime
>> footprint overheads are small. And .01 seems to add a BSM for every
>> enum switch, so while we reduce compiled classes we add other
>> overheads.
>>
>> I think it'd be good, for the sake of argument, to examine the exact
>> size of lib/modules with baseline, .00, and .01. My gut feeling is the
>> gain from the approach in .01 is smaller than it first appears.
>
> So, I think the outcomes are more interesting than I expected. I ran:
> find . -name "*.class" | wc -l
> and
> find . -name "*.class" | xargs cat | wc -c
>
> For the exploded JDK images with version .00 and .01 of the patch and 
> unmodified.
>
> Unmodified: 134400902 bytes, 30267 classes, jdk.compiler size: 7746387b
> patch .00:  134476598 bytes, 30412 classes, jdk.compiler size: 7777182b
> patch .01:  134637774 bytes, 30270 classes, jdk.compiler size: 7806442b
>
> So, with the .01 patch, the total size seems to be bigger than with 
> the .00 patch. This is partly because there is more code in javac 
> (jdk.compiler), but I also took a look at a few classes:
> with patch version .00:
> jdk/modules/java.base/java/lang/invoke/VarHandle$2.class:
> 933 bytes
>
> jdk/modules/java.base/java/lang/invoke/VarHandle$3.class:
> 914 bytes
>
> jdk/modules/java.base/java/lang/invoke/VarHandle$VarHandleDesc.class: 
> 4427 bytes
>
> with patch version .01:
> jdk/modules/java.base/java/lang/invoke/VarHandle$2.class:
> 1847 bytes
>
> jdk/modules/java.base/java/lang/invoke/VarHandle$VarHandleDesc.class:
> 4553 bytes
>
> (the VarHandle$2.class here contains code that is in VarHandle$2.class 
> and VarHandle$3.class with patch version .00)
>
> The difference in the VarHandle$VarHandleDesc.class appears to be 
> mostly the difference in describing the bootstrap method. It is true 
> currently the generated bootstrap's name is fairly long, so with a 
> shorter name, the difference would be smaller, and version .01 might 
> get even smaller than version .00 (I didn't measure/try that (yet)).
>
> So I think you are right that the gain with .01 is probably much 
> smaller than it might appear.
>
> Jan
>
>>
>> (That said I think there is intrinsic value in exploring and using
>> condy for things like this.)
>>
>> Thanks!
>>
>> /Claes