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

[Peter Levart]

On 12/18/2012 01:50 AM, David Holmes wrote:
> Hi Peter,
>
> BTW JEP-149 not 146!
Sorry, my bad ;-(

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

Does M6 mean that no more such enhancement will be accepted before 
release of JDK8? I guess annotations are a different category because 
there is a lot of new stuff coming in that will need to be optimized as 
well.

Regards, Peter

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