EnumData space optimization in j.l.Class (JEP-146)

[David Holmes]

Hi Peter,

BTW JEP-149 not 146!

Sorry I didn't get a chance to respond last night before you continued 
on this path. I have to say no to this too. First I am just running out 
of time to get this finalized by M6 - particularly with the Xmas break 
looming.

Second the trade-off here is far less clear. Not only may the 
performance aspect be more significant (as per Remi's discussion) but 
the memory saving may not even eventuate depending on alignment.

It may be worth doing a new JEP for continued enhancements in this area 
post JDK 8, or maybe just have a RFE filed. But for now I have to put 
the brakes on and just run with what we have with the reflection caching 
changes.

Your efforts are very much appreciated - I just wish the timing could 
have been different.

Thanks,
David

On 18/12/2012 1:36 AM, Peter Levart wrote:
> Hi David and others,
>
> Here's a patch that eliminates one of two fields in java.lang.Class,
> related to caching enum constants:
>
> http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149.enum/webrev.01/index.html
>
> It does it by moving one field to a subclass of HashMap, which is
> referenced by a remaining field that serves two different
> purposes/stages of caching.
>
> These are the results of a micro-benchmark that exercises public API
> that uses the internal j.l.Class API regarding enum constants:
>
> enum MyEnum { ONE, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN }
> EnumSet.noneOf(MyEnum.class): 300_000_000 loops
> MyEnum.valueOf(String): 30_000_000 loops * 10 calls for different names
>
> ** Original JDK8 code
>
> Executing: /home/peter/Apps64/jdk1.8.0-jdk8-tl/bin/java -Xmx4G -cp
> ../out/production/test test.EnumTest reference
>
> EnumSet.noneOf(Class): 351610312 340302968 339893333 339774384 339750612
> 339558414 339547022 339621595
> MyEnum.valueOf(String): 935153830 897188742 887541353 960839820
> 886119463 885818334 885827093 885752461
> EnumSet.noneOf(Class): 339552678 339469528 339513757 339451341 339512154
> 339511634 339664326 339793144
>
> ** patched java.lang.Class
>
> Executing: /home/peter/Apps64/jdk1.8.0-jdk8-tl/bin/java -Xmx4G -cp
> ../out/production/test -Xbootclasspath/p:../out/production/jdk test.EnumTest
>
> EnumSet.noneOf(Class): 351724931 339286591 305082929 305042885 305058303
> 305044144 305073463 305049604
> MyEnum.valueOf(String): 955032718 908534137 891406394 891506147
> 891414312 893652469 891412757 891409294
> EnumSet.noneOf(Class): 414044087 406904161 406788898 406839824 406765274
> 406815728 407002576 406779162
>
> The slow-down of about 20% (last line) is presumably a consequence of
> another in-direction to obtain shared enum constants array when there is
> already a Map in place. It is still fast though (300M EnumSet instances
> / 0.4 s).
>
> Here's the source of the micro-benchmark:
>
> https://raw.github.com/plevart/jdk8-tl/JEP-149.enum/test/src/test/EnumTest.java
>
> I don't know what's more important in this occasion. A small space gain
> (8 or 4 bytes per j.l.Class instance) or a small performance gain (20%).
>
> Regards, Peter
>