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
