On 11/05/2012 06:23 AM, David Holmes wrote:
Hi Peter,
Moving the annotations fields into a helper object would tie in with
the Class-instance size reduction effort that was investigated as part
of "JEP 149: Reduce Core-Library Memory Usage":
http://openjdk.java.net/jeps/149
The investigations there to date only looked at relocating the
reflection related fields, though the JEP mentions the annotations as
well.
Any such effort requires extensive benchmarking and performance
analysis before being accepted though.
David
-----
On 11/05/2012 10:25 AM, Alan Bateman wrote:
Here's a good starting place on the interaction of runtime visible
attributes and RedefineClasses/RetransformClasses:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5002251
-Alan.
Hi all,
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;
So let's look at static overhead differences using 64 bit addressing
(useful load - 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 = 10*8+4 = 84 bytes in 1 instance
vs. patched code :
1 OOP = 8 bytes in 1 instance
* Fully loaded java.lang.Class (Fields, Methods, Constructors,
annotations):
current JDK8 code:
10 OOPs + 1 int = 84 bytes
8 SoftReference instances = 8*(header + 4 OOPs + 1 long) =
8*(24+32+8) =
8*64 = 512 bytes
total: 84+512 = 596 bytes in 9 instances
vs. patched code :
1 OOP = 8 bytes
1 SoftReference = 64 bytes
1 VolatileData = header + 10 OOPs + 1 int = 24+84 = 108 bytes
total: 8+64+108 = 180 bytes in 3 instances
So we have 84 vs. 8 (empty) or 596 vs. 180 (fully loaded) byte
overheads and
1 vs. 1 (empty) or 9 vs. 3 (fully loaded) instance overheads
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.
The patch against jdk8/jdk8/jdk hg repository is here:
https://raw.github.com/plevart/jdk8-hacks/master/volatile_class_data_caching.patch
You can also browse the changed sources:
https://github.com/plevart/jdk8-hacks
Regards, Peter