Community
Participate
Working Groups
Build 3.2RC7 An enum type is generated 2 methods: #values() and #valueOf(String). These should be reworked to do: 1. #values() use array clone 2. #valueOf(String) reuse Enum#valueOf(String,Class) which internally is map based and thus much more efficient in large cases.
Actually, arraycopy for (1) is debattable.
Note that (2) will take care of addressing bug 145732
re: (2) I wonder how common it is to have such a large number of enum constants? I would expect an easily JIT-optimized for-loop with known limits would be more efficient in the most common cases. However, if you dispatch to the Enum type then it becomes their problem<g>.
It also makes the classfile more compact, since using one indirection. I wonder about scenarii where #valueOf(...) would be extensively used, as opposed to direct reference to enum constants. Feels like reflecting upon the enum.
Created attachment 43713 [details] Proposed patch
Olivier - pls double check
Releasing for 3.2.1 since it will impact other bug 145732, which matters for Harmony
Created attachment 43866 [details] Complement to the first patch Fix comments + remove unused field and methods from the CodeStream/StackMapCodeStream and ConstantPool.
Created attachment 43872 [details] New patch Forgot one change in the StackMapCodeStream
Fix also released for 3.3M1
Released for 3.2.1 Released for 3.3 M1
Verified for 3.3 M1 using build I20060807-2000.
Verified for 3.2.1 using build M20060908-1655
