This repository has been archived by the owner on Oct 19, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
volatile_class_data_caching.txt
188 lines (115 loc) · 8.69 KB
/
volatile_class_data_caching.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
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<Field[]> declaredFields;
private volatile transient SoftReference<Field[]> publicFields;
private volatile transient SoftReference<Method[]> declaredMethods;
private volatile transient SoftReference<Method[]> publicMethods;
private volatile transient SoftReference<Constructor<T>[]> declaredConstructors;
private volatile transient SoftReference<Constructor<T>[]> publicConstructors;
private volatile transient SoftReference<Field[]> declaredPublicFields;
private volatile transient SoftReference<Method[]> 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<Class<? extends Annotation>, Annotation> annotations;
private transient Map<Class<? extends Annotation>, 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<T>> volatileData;
...which is a SoftReference to the following structure:
// volatile data that might get invalid when JVM TI RedefineClasses() is called
static class VolatileData<T> {
volatile Field[] declaredFields;
volatile Field[] publicFields;
volatile Method[] declaredMethods;
volatile Method[] publicMethods;
volatile Constructor<T>[] declaredConstructors;
volatile Constructor<T>[] publicConstructors;
// Intermediate results for getFields and getMethods
volatile Field[] declaredPublicFields;
volatile Method[] declaredPublicMethods;
// Annotations
volatile Map<Class<? extends Annotation>, Annotation> annotations;
volatile Map<Class<? extends Annotation>, 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.