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

[Jan Lahoda]

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