Peter,
Many thanks for preparing that patch. As we're leaving annotations
behind lets continue any further discussion of this patch in a new email
thread specific to JEP-149.
I'll run this patch through some basic testing and performance benchmarks.
The JEP will also need updating so I'll be
Hi Peter,
On 12/12/12 4:31 AM, Peter Levart wrote:
Hi all,
Ok, no problem. So here's a patch that summarizes what I did in the
previous patch, but only for reflective fields (Field[], Method[],
Constructor[]) not including annotations:
http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149.c/web
On 12/12/2012 04:34 PM, Peter Levart wrote:
On 12/12/2012 11:59 AM, Joel Borggrén-Franck wrote:
Hi all,
First, thanks all of you that are involved in this!
I agree with David here, lets split this up (for now) and do
reflective objects in the context of jep-149 and annotations separately.
A
On 12/12/2012 11:59 AM, Joel Borggrén-Franck wrote:
Hi all,
First, thanks all of you that are involved in this!
I agree with David here, lets split this up (for now) and do reflective objects
in the context of jep-149 and annotations separately.
As you may know there are even more annotation
Hi all,
Ok, no problem. So here's a patch that summarizes what I did in the
previous patch, but only for reflective fields (Field[], Method[],
Constructor[]) not including annotations:
http://dl.dropbox.com/u/101777488/jdk8-tl/JEP-149.c/webrev/index.html
The annotations part is unchanged sem
Hi all,
First, thanks all of you that are involved in this!
I agree with David here, lets split this up (for now) and do reflective objects
in the context of jep-149 and annotations separately.
As you may know there are even more annotation coming in with JSR 308
annotations on type (use), so
from elsewhere, not guarded by the synchronization.
So all in all the two aspects - annotations and basic reflection
stuff - are quite intermingled in current code, unfortunately very
inconsistently. I'm afraid that doing one thing and not touching
the other is possible, but
re quite intermingled in current code, unfortunately very
inconsistently. I'm afraid that doing one thing and not touching the
other is possible, but that would not solve the problems that this
thread was starting to address (bottleneck by
java.lang.Class.getAnnotations()) and evident dead-
s and basic reflection
stuff - are quite intermingled in current code, unfortunately very
inconsistently. I'm afraid that doing one thing and not touching the
other is possible, but that would not solve the problems that this
thread was starting to address (bottleneck by
java.lang.Class.getAnnot
re, not guarded by the synchronization.
So all in all the two aspects - annotations and basic reflection
stuff - are quite intermingled in current code, unfortunately very
inconsistently. I'm afraid that doing one thing and not touching the
other is possible, but
ingled in current code, unfortunately very
inconsistently. I'm afraid that doing one thing and not touching the
other is possible, but that would not solve the problems that this
thread was starting to address (bottleneck by
java.lang.Class.getAnnotations()) and evident dead-lock bugs.
We
doing one thing and not touching the
other is possible, but that would not solve the problems that this
thread was starting to address (bottleneck by
java.lang.Class.getAnnotations()) and evident dead-lock bugs.
We can approach the problem so that we separate the aspects of caching
Class-level a
Hi Peter,
Sorry for the delay on this.
Generally your VolatileData and my ReflectionHelper are doing a similar
job. But I agree with your reasoning that all of the cached
SoftReferences are likely to be cleared at once, and so a SoftReference
to a helper object with direct references, is more
Hi David, Alan, Alexander and others,
In the meanwhile I have added another annotations space optimization to
the patch. If a Class doesn't inherit any annotations from a superclass,
which I think is a common case, it assigns the same Map instance to
"annotations" as well as "declaredAnnotatio
On 1/12/2012 4:54 AM, Alan Bateman wrote:
On 30/11/2012 18:36, Peter Levart wrote:
:
So, what do you think? What kind of tests should I prepare in addidion
to those 3 so that the patch might get a consideration?
I think this is good work and thanks for re-basing your patch. I know
David plans
On 30/11/2012 18:36, Peter Levart wrote:
:
So, what do you think? What kind of tests should I prepare in addidion
to those 3 so that the patch might get a consideration?
I think this is good work and thanks for re-basing your patch. I know
David plans to do a detail review. I think it will req
Hi Alan, David, Alexander and others,
I noticed the push of Joe Darcy's code for repeating annotations which
makes my proposed patch not entirely compatible with new code. So I
rebased the patch to current code in jdk8/tl/jdk repository. I had to
revert my last improvement (the replacement of
Hi again,
I have found an inconsistency in the last patch I posted. Specifically
the Method.getAnnotation(Class) and Constructor.getAnnotation(Class) did
not delegate to the root instance as .getAnnotations() did. I corrected
that in new revision of the patch:
http://dl.dropbox.com/u/1017774
Hi David, Alan, Alexander and others,
Here's a refinement of a patch I proposed in this thread a couple of
weeks ago:
http://dl.dropbox.com/u/101777488/jdk8-hacks/JEP-149/webrev.02/index.html
The changed sources can be browsed here:
https://github.com/plevart/jdk8-hacks/tree/annotation-array
Hi all,
I have redone the static memory footprint comparison calculations
(taking correct object headers and padding into account) and I hope this
time I've done it right. Here's what I got:
64bit addressing (16 byte object header):
patched Class uses 76 bytes less than original Class when e
On Wed, Nov 7, 2012 at 11:02 AM, Peter Levart wrote:
> On 11/07/2012 06:59 PM, Martin Buchholz wrote:
>
> We've also seen deadlocks in accessing annotations in the wild.
> So, many thanks for working on this (both performance improvements and
> deadlock removal).
> We don't have a test case to c
On 11/07/2012 06:59 PM, Martin Buchholz wrote:
We've also seen deadlocks in accessing annotations in the wild.
So, many thanks for working on this (both performance improvements and
deadlock removal).
We don't have a test case to contribute, but here's a stacktrace:
That's one thread. What abo
We've also seen deadlocks in accessing annotations in the wild.
So, many thanks for working on this (both performance improvements and
deadlock removal).
We don't have a test case to contribute, but here's a stacktrace:
sun.reflect.annotation.AnnotationType.getInstance(AnnotationType.java:80)
On 11/06/2012 08:37 AM, Peter Levart wrote:
Hi all,
I have prepared a better patch. It addresses the goals of JEP-149 more
seriously. I also have some benchmarks. Stay tuned...
Regards, Peter
For easier viewing, here's also a webrev:
http://dl.dropbox.com/u/101777488/jdk8-hacks/JEP-149/
On 11/07/2012 03:10 AM, David Holmes wrote:
Hi Peter,
The movement of the reflection caches to a helper object is exactly
what I had previously proposed here (some differences in the details
of course):
http://cr.openjdk.java.net/~dholmes/JEP-149/webrev/
and discussed here:
http://mail.ope
Hi Peter,
The movement of the reflection caches to a helper object is exactly what
I had previously proposed here (some differences in the details of course):
http://cr.openjdk.java.net/~dholmes/JEP-149/webrev/
and discussed here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-Apr
On 11/06/2012 03:00 PM, Alan Bateman wrote:
Peter,
I haven't studied your patch yet but moving the fields into a helper
class is what was envisaged. Here's another reminder that the
initialization has been crying out to be re-worked for some time:
http://bugs.sun.com/view_bug.do?bug_id=71221
Peter,
I haven't studied your patch yet but moving the fields into a helper
class is what was envisaged. Here's another reminder that the
initialization has been crying out to be re-worked for some time:
http://bugs.sun.com/view_bug.do?bug_id=7122142
-Alan.
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 investigatio
Hi all,
I have prepared a better patch. It addresses the goals of JEP-149 more
seriously. I also have some benchmarks. Stay tuned...
Regards, Peter
On Nov 6, 2012 2:29 AM, "David Holmes" wrote:
> Hi Alex,
>
> On 5/11/2012 11:36 PM, Alexander Knöller wrote:
>
>> Hi David.
>>
>> What about my pro
Hi Alex,
On 5/11/2012 11:36 PM, Alexander Knöller wrote:
Hi David.
What about my proposal for a simple double-checked-locking for the redefinitions fields
and the use of local variables for "annotations" in
getAnnotations() and initAnnotationsIfNecessary() ?
Sorry I thought Peter's proposed
Hi David.
What about my proposal for a simple double-checked-locking for the
redefinitions fields and the use of local variables for "annotations" in
getAnnotations()
and
initAnnotationsIfNecessary()
?
Are additional local Variables similar "bad habit" for memory usage (although
they only affect
On 04/11/2012 20:27, Peter Levart wrote:
:
I digress. Javadocs say: "The redefinition may change method bodies,
the constant pool and attributes. The redefinition must not add,
remove or rename fields or methods, change the signatures of methods,
or change inheritance. These restrictions maybe
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 th
Hi,
I propose the following patch to java.lang.Class in order to overcome
the synchronization bottleneck when accessing annotations from multiple
threads. The patch packs the 'annotations' and 'declaredAnnotations'
Maps together with an int redefinedCount into a structure:
static class A
he lock on
initAnnotationsIfNecessary()).
Regards
Alex
Anfang der weitergeleiteten E-Mail:
Von: Alexander Knöller
Betreff: Re: bottleneck by java.lang.Class.getAnnotations()
Datum: 2. November 2012 08:43:06 MEZ
An: Joe Darcy
Kopie: Alan Bateman ,
[email protected]
I know. But there is a usual s
Anfang der weitergeleiteten E-Mail:
Von: Alexander Knöller
Betreff: Re: bottleneck by java.lang.Class.getAnnotations()
Datum: 2. November 2012 08:43:06 MEZ
An: Joe Darcy
Kopie: Alan Bateman , [email protected]
I know. But there is a usual solution to those kind of problems: double checked
locking.
er
> Betreff: Re: bottleneck by java.lang.Class.getAnnotations()
> Datum: 2. November 2012 08:43:06 MEZ
> An: Joe Darcy
> Kopie: Alan Bateman , [email protected]
>
> I know. But there is a usual solution to those kind of problems: double
> checked locking.
> This wo
38 matches
Mail list logo
