Presented here is a patch mainly against java.lang.Class and also against java.lang.reflect.[Field,Method,Constructor,Executable] classes. Currently java.lang.Class uses the following fields to maintain caches of reflection data that are invalidated as a result of class or superclass redefinition/re-transformation: private volatile transient SoftReference declaredFields; private volatile transient SoftReference publicFields; private volatile transient SoftReference declaredMethods; private volatile transient SoftReference publicMethods; private volatile transient SoftReference[]> declaredConstructors; private volatile transient SoftReference[]> publicConstructors; private volatile transient SoftReference declaredPublicFields; private volatile transient SoftReference declaredPublicMethods; // Value of classRedefinedCount when we last cleared the cached values // that are sensitive to class redefinition. private volatile transient int lastRedefinedCount = 0; // Annotations cache private transient Map, Annotation> annotations; private transient Map, Annotation> declaredAnnotations; If I understand Alan's references correctly, current VM can redefine the class in a way that changes method bodies. Also new methods can be added. And the set of annotations can also be altered. And future improvements could allow even more. Because annotations are cached on Field/Method/Constructor instances, all the above fields must be invalidated when the class or superclass is redefined. It can also be observed that Field/Method/Constructor caches are maintained using SoftReferences but annotations are hard references. I don't know if this is intentional. I believe that annotations could also be SoftReferenced, so that in the event of memory pressure they get cleared. Many applications retrieve annotations only in the early stages of their life-cycle and then either cache them themselves or forget about them. So I designed the patch to equalize this. If this is undesirable, the patch could be modified to make a distinction again. The patch replaces the above-mentioned java.lang.Class fields with a single field: private volatile transient SoftReference> volatileData; ...which is a SoftReference to the following structure: // volatile data that might get invalid when JVM TI RedefineClasses() is called static class VolatileData { volatile Field[] declaredFields; volatile Field[] publicFields; volatile Method[] declaredMethods; volatile Method[] publicMethods; volatile Constructor[] declaredConstructors; volatile Constructor[] publicConstructors; // Intermediate results for getFields and getMethods volatile Field[] declaredPublicFields; volatile Method[] declaredPublicMethods; // Annotations volatile Map, Annotation> annotations; volatile Map, Annotation> declaredAnnotations; // Value of classRedefinedCount when we created this VolatileData instance final int redefinedCount; Let's look at static memory usage using 64 bit addressing (non-affected fields and useful data - arrays, Maps not counted since the patched code uses the same amount of same types of each). * Fresh java.lang.Class instance: current JDK8 code: 10 OOPs + 1 int + 0byte padding = 10*8+4 = 84 bytes in 1 instance vs. patched code : 1 OOP + 4byte padding = 12 bytes in 1 instance * Fully loaded java.lang.Class (Fields, Methods, Constructors, annotations): - current JDK8 code: 10 OOPs + 1 int + 0byte padding = 84 bytes 8 SoftReference instances = 8*(header + 4 OOPs + 1 long) = 8*(16+32+8) = 8*56 = 448 bytes total: 84+448 = 532 bytes in 9 instances - vs. patched code : 1 OOP + 4byte padding = 12 bytes 1 SoftReference = 56 bytes 1 VolatileData = header + 10 OOPs + 1 int + 4byte padding = 16+84+4 = 104 bytes total: 12+56+104 = 172 bytes in 3 instances * Just one field loaded (say declaredMethods) - current JDK8 code: 10 OOPs + 1 int + 0byte padding = 84 bytes 1 SoftReference instance = 56 bytes total: 84+56 = 140 bytes in 2 instances - vs. patched code : 1 OOP + 4byte padding = 12 bytes 1 SoftReference = 56 bytes 1 VolatileData = header + 10 OOPs + 1 int + 4byte padding = 16+84+4 = 104 bytes total: 12+56+104 = 172 bytes in 3 instances And here's the same calculation using 32 bit addressing: * Fresh java.lang.Class instance: - current JDK8 code: 10 OOPs + 1 int + 0byte padding = 10*4+4 = 44 bytes in 1 instance - vs. patched code : 1 OOP + 0byte padding = 4 bytes in 1 instance * Fully loaded java.lang.Class (Fields, Methods, Constructors, annotations): - current JDK8 code: 10 OOPs + 1 int + 0byte padding = 44 bytes 8 SoftReference instances = 8*(header + 4 OOPs + 1 long) = 8*(8+16+8) = 8*32 = 256 bytes total: 44+256 = 300 bytes in 9 instances - vs. patched code : 1 OOP + 0byte padding = 4 bytes 1 SoftReference = 32 bytes 1 VolatileData = header + 10 OOPs + 1 int + 4byte padding = 8+40+4 = 56 bytes total: 4+32+56 = 92 bytes in 3 instances * Just one field loaded (say declaredMethods) - current JDK8 code: 10 OOPs + 1 int + 0byte padding = 44 bytes 1 SoftReference instance = 32 bytes total: 44+32 = 76 bytes in 2 instances - vs. patched code : 1 OOP + 0byte padding = 4 bytes 1 SoftReference = 32 bytes 1 VolatileData = header + 10 OOPs + 1 int + 4byte padding = 56 bytes total: 4+32+56 = 92 bytes in 3 instances To sum: 64bit addressing (16 byte object header): patched Class uses 84-8 = 76 bytes less than original Class when empty patched Class uses 532-172 = 360 bytes less than original Class when fully loaded patched Class uses 172-140 = 32 bytes more than original Class when just one of fields is loaded 32bit addressing (8 byte object header): patched Class uses 44-4 = 40 bytes less than original Class when empty patched Class uses 300-92 = 208 bytes less than original Class when fully loaded patched Class uses 92-76 = 16 bytes more than original Class when just one of fields is loaded object instance counts: patched Class uses the same number of object instances as original Class when empty patched Class uses 9-3 = 6 object instances less than original Class when fully loaded patched Class uses 3-2 = 1 object instance more than original Class when just one of fields is loaded Other than that, the patch also removes synchronized blocks for lazy initialization of annotations in Class, Field, Method and Constructor and replaces them with volatile fields. In case of Class.volatileData, this field is initialized using a CAS so there is no race which could install an already stale instance over more recent. Although such race would quickly be corrected at next call to any retrieval method, because redefinedCount is now an integral part of the cached structure not an individual volatile field. There is also a change in how annotations are cached in Field, Method and Constructor. Originally they are cached in each copy of the Field/Method/Constructor that is returned to the outside world at each invocation of Class.getFields() etc. Such caching is not very effective if the annotations are only retrieved once per instance. The patch changes this and delegates caching to the "root" instance which is held inside Class so caching becomes more effective in certain usage patterns. There's now a possible hot-spot on the "root" instance but that seems not to be a bottleneck since the fast-path does not involve blocking synchronization (just volatile read). The effects of this change are clearly visible in one of the benchmarks. I have tried to create 3 micro benchmarks which exercise concurrent load on 3 Class instances. Here's the benchmark code: https://raw.github.com/plevart/jdk8-hacks/master/src/test/ReflectionTest.java And here are the results when run on an Intel i7 CPU (4 cores, 2 threads/core) Linux machine using -Xmx4G VM option: https://raw.github.com/plevart/jdk8-hacks/master/benchmark_results.txt The huge difference of Test1 results is a direct consequence of patched code delegating caching of annotations in Field/Method/Constructor to the "root" instance. Test2 results show no noticeable difference between original and patched code. This, I believe, is the most common usage of the API, so another level of indirection does not appear to present any noticeable performance overhead. The Test3 on the other hand shows the synchronization overhead of current jdk8 code in comparison with non-blocking synchronization in patched code. JEP 149 also mentions testing with SPECjbb2005 and SPECjvm98, but that exceeds my possibilities.