EnumData space optimization in j.l.Class (JEP-149)
David Holmes
david.holmes at oracle.com
Tue Dec 18 09:36:50 UTC 2012
On 18/12/2012 7:24 PM, Peter Levart wrote:
> 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.
M6 is the "feature complete" milestone. There may be some features that
are known to not be complete by that time - I can't say if annotations
will be one or not. Obviously this doesn't mean everything is 100%
finalized and bug free, but the essence of the feature has to be there.
MY understanding of this is that I have to have the "final form" of
JEP-149 finished by then. This includes basic testing and performance
measurements - and so I need a stable "target".
Whether there is room for further adjustments after M6 I really can't say.
Thanks,
David
> 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
>>>
>
More information about the core-libs-dev
mailing list