On 04/27/2013 11:37 AM, Alan Bateman wrote:
On 27/04/2013 00:13, Mandy Chung wrote:
Peter,
I have pushed the changeset:
Changeset: 5e7ae178b24d
Author:plevart
Date: 2013-04-26 16:09 -0700
URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7ae178b24d
Mandy
This is great work,
On 27/04/2013 00:13, Mandy Chung wrote:
Peter,
I have pushed the changeset:
Changeset: 5e7ae178b24d
Author:plevart
Date: 2013-04-26 16:09 -0700
URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7ae178b24d
Mandy
This is great work, thank you!
-Alan.
Hi Mandy,
Just a note on null keys (1st level)...
On 04/25/2013 11:53 PM, Mandy Chung wrote:
Hi Peter,
This looks great. I have imported your patch with slight modification
in WeakCache:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7123493/webrev.01/
I believe WeakCache.get(K, P)
On 4/25/2013 11:53 PM, Peter Levart wrote:
I believe WeakCache.get(K, P) should throw NPE if key is null and I
fixed that.
Oops... typo sorry for the confusion.- I meant WeakCache.containsKey(V
value) should throw NPE if value is null.
Mandy
On 04/26/2013 08:57 AM, Mandy Chung wrote:
On 4/25/2013 11:53 PM, Peter Levart wrote:
I believe WeakCache.get(K, P) should throw NPE if key is null and I
fixed that.
Oops... typo sorry for the confusion.- I meant WeakCache.containsKey(V
value) should throw NPE if value is null.
I
Peter,
I have pushed the changeset:
Changeset: 5e7ae178b24d
Author:plevart
Date: 2013-04-26 16:09 -0700
URL:http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5e7ae178b24d
Mandy
Hi Mandy,
Here's another update that changes the sub-key back to
WeakReferenceClass based:
http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.05/index.html
On 04/25/2013 03:38 AM, Mandy Chung wrote:
I like this one too. The mapping is straight forward and clean that
Hi Peter,
This looks great. I have imported your patch with slight modification
in WeakCache:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7123493/webrev.01/
I believe WeakCache.get(K, P) should throw NPE if key is null and I
fixed that. I changed refQueue to be of type
Hi Mandy,
On 04/24/2013 01:43 AM, Mandy Chung wrote:
Hi Peter,
Sorry for the delay.
On 4/20/2013 12:31 AM, Peter Levart wrote:
Hi Mandy,
I have another idea. Before jumping to implement it, I will first ask
what do you think of it. For example:
- have an optimal interface names key
On 04/24/2013 07:33 AM, Mandy Chung wrote:
More comments in addition to what I replied earlier
On 4/23/2013 4:43 PM, Mandy Chung wrote:
Each ClassLoader maintains explicit hard-references to all Class
objects for classes defined by the loader. So proxy Class object can
not be GC-ed
On 04/24/2013 01:43 AM, Mandy Chung wrote:
Precise check should be to validate if the given interfaces == the
proxy interfaces implemented by the cached proxy class (i.e.
proxyClass.getInterfaces()).
Hi Mandy,
I will try to profile this approach as a post-validation and let you
know the
On 04/24/2013 09:16 AM, Peter Levart wrote:
On 04/24/2013 01:43 AM, Mandy Chung wrote:
Precise check should be to validate if the given interfaces == the
proxy interfaces implemented by the cached proxy class (i.e.
proxyClass.getInterfaces()).
Hi Mandy,
I will try to profile this approach
Hi Mandy,
I have noticed recently on the hotspot-runime-dev mailing list:
RFR(XXS): 8012714: Assign the unique traceid directly to the Klass upon
creation...
Could this be accessed from Java? It looks like a perfect key to
identify a class within a JVM. Can it be represented as int or long?
On 4/23/2013 11:58 PM, Peter Levart wrote:
The isAssignableFrom check should be correct for well-behaved class
loaders [1]. However, for non well-behaved class loaders, I'm not
absolutely confident that this is right. The case that I was
concerned is when intf.isAssignableFrom(proxyClass)
Hi Peter,
We both prefer the interface types as the subKey.See my comment
inlined below.
On 4/23/2013 11:58 PM, Peter Levart wrote:
I developed two different approaches:
1. Key made of WeakReference-s to interface Class objects.
Strong points:
- no key aliasing, validation can be pushed
On 04/23/2013 05:27 AM, Mandy Chung wrote:
On 4/21/2013 6:39 AM, Peter Levart wrote:
On 04/21/2013 04:52 AM, Mandy Chung wrote:
Hi Peter,
I want to give it some more thought and discuss with you next week.
As for the zero number of interface, I think it's a bug and it
should throw IAE if
On 4/22/2013 11:24 PM, Peter Levart wrote:
On 04/23/2013 05:27 AM, Mandy Chung wrote:
On 4/21/2013 6:39 AM, Peter Levart wrote:
On 04/21/2013 04:52 AM, Mandy Chung wrote:
Hi Peter,
I want to give it some more thought and discuss with you next
week. As for the zero number of interface, I
Hi Peter,
Sorry for the delay.
On 4/20/2013 12:31 AM, Peter Levart wrote:
Hi Mandy,
I have another idea. Before jumping to implement it, I will first ask
what do you think of it. For example:
- have an optimal interface names key calculated from interfaces.
- visibility of interfaces and
More comments in addition to what I replied earlier
On 4/23/2013 4:43 PM, Mandy Chung wrote:
Each ClassLoader maintains explicit hard-references to all Class
objects for classes defined by the loader. So proxy Class object can
not be GC-ed until the ClassLoader is GC-ed.
AFAIU, a
On 4/21/2013 6:39 AM, Peter Levart wrote:
On 04/21/2013 04:52 AM, Mandy Chung wrote:
Hi Peter,
I want to give it some more thought and discuss with you next week.
As for the zero number of interface, I think it's a bug and it should
throw IAE if the given interfaces array is empty.
On 04/21/2013 04:52 AM, Mandy Chung wrote:
Hi Peter,
I want to give it some more thought and discuss with you next week.
As for the zero number of interface, I think it's a bug and it should
throw IAE if the given interfaces array is empty. Thanks for finding
it and I'll file a separate
Hi Mandy,
I have another idea. Before jumping to implement it, I will first ask
what do you think of it. For example:
- have an optimal interface names key calculated from interfaces.
- visibility of interfaces and other validations are pushed to slow-path
(inside ProxyClassFactory.apply)
-
On 04/20/2013 09:31 AM, Peter Levart wrote:
Hi Mandy,
I have another idea. Before jumping to implement it, I will first ask
what do you think of it. For example:
- have an optimal interface names key calculated from interfaces.
- visibility of interfaces and other validations are pushed to
Hi Mandy,
On 04/19/2013 07:33 AM, Mandy Chung wrote:
https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.02/index.html
What about package-private in java.lang.reflect? It makes Proxy
itself much easier to read. When we decide which way to go, I can
remove the interface
On 04/19/2013 04:36 PM, Peter Levart wrote:
http://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc-wi/webrev.01/index.html
Hi Mandy,
I changed the copyright header of WeakCache to GPLv2 with ClassPath
exception and corrected a minor formatting inconsistency:
Hi Mandy,
I just noticed the following (have been thinking of it already, but then
forgot) in original code:
/*
512 * Note that we need not worry about reaping the cache for
513 * entries with cleared weak references because if a proxy
class
514 *
Hi Peter,
On 4/17/13 7:18 AM, Peter Levart wrote:
As expected, the Proxy.getProxyClass() is yet a little slower than
with FlattenedWeakCache, but still much faster than original Proxy
implementation. Another lookup in the ConcurrentHashMap and another
indirection have a price, but we also get
Hi Mandy,
Here's the updated webrev:
https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy-wc/webrev.02/index.html
This adds TwoLevelWeakCache to the scene with following performance
compared to other alternatives:
Summary (4 Cores x 2 Threads i7 CPU):
Test
Hi Mandy,
I prepared a preview variant of j.l.r.Proxy using WeakCache (turned into
an interface and a special FlattenedWeakCache implementation in
anticipation to create another variant using two-levels of
ConcurrentHashMaps for backing storage, but with same API) just to
compare
On 4/16/2013 7:18 AM, Peter Levart wrote:
Hi Mandy,
I prepared a preview variant of j.l.r.Proxy using WeakCache (turned
into an interface and a special FlattenedWeakCache implementation in
anticipation to create another variant using two-levels of
ConcurrentHashMaps for backing storage, but
On 4/13/2013 2:59 PM, Peter Levart wrote:
I also devised an alternative caching mechanism with scalability in
mind which uses WeakReferences for keys (for example ClassLoader)
and values (for example Class) that could be used in this situation
in case adding a field to ClassLoader is not
Hi Mandy,
On 04/12/2013 11:31 PM, Mandy Chung wrote:
Hi Peter,
Thank you for rebasing the patch. This is very good work and I hope to
make time to work with you to get your patch to jdk8 over the next
couple weeks.
I hope I can be of assistance,
On 4/10/2013 5:35 AM, Peter Levart wrote:
Hi Peter,
Thank you for rebasing the patch. This is very good work and I hope to
make time to work with you to get your patch to jdk8 over the next
couple weeks.
On 4/10/2013 5:35 AM, Peter Levart wrote:
Hi Alan,
I have prepared new webrev of the patch rebased to current tip of
jdk8/tl
Hi Alan,
I have prepared new webrev of the patch rebased to current tip of
jdk8/tl repo:
https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy/webrev.04/index.html
I noticed there were quite a few changes to the j.l.r.Proxy in the
meanwhile regarding new security checks. But
On 4/10/2013 5:35 AM, Peter Levart wrote:
Hi Alan,
I have prepared new webrev of the patch rebased to current tip of
jdk8/tl repo:
https://dl.dropboxusercontent.com/u/101777488/jdk8-tl/proxy/webrev.04/index.html
I noticed there were quite a few changes to the j.l.r.Proxy in the
Hi Alan,
Is this still being considered? Recently there were some changes in the
j.l.r.Proxy (the @CallerSensitive annotation), so my final webrev of the
patch will have to be rebased. Do you still think we should not add new
fields to ClassLoader? I have some ideas how to do it without
On 25/01/2013 17:55, Peter Levart wrote:
:
The solution is actually very simple. I just want to validate my
reasoning before jumping to implement it:
- for solving scalability of getProxyClass cache, a field with a
reference to ConcurrentHashMapListString, Class? extends Proxy
is added to
On 01/28/2013 12:49 PM, Alan Bateman wrote:
On 25/01/2013 17:55, Peter Levart wrote:
:
The solution is actually very simple. I just want to validate my
reasoning before jumping to implement it:
- for solving scalability of getProxyClass cache, a field with a
reference to
Hi Alan,
I prepared the variant with lazy initialization of ConcurrentHashMaps
per ClassLoader and performance measurements show no differences. So
here's this variant:
* http://dl.dropbox.com/u/101777488/jdk8-tl/proxy/webrev.03/index.html
I also checked the ClassLoader layout and as it
On 01/25/2013 06:35 AM, David Holmes wrote:
On 25/01/2013 2:36 AM, Peter Levart wrote:
On 01/24/2013 04:45 PM, Peter Levart wrote:
Is there really no existing alignment gap in j.l.Class layout that a
boolean can slide into?
There might be, I will check.
All instance fields in j.l.Class are
That's unfortunate. Can you steal a bit in one of the int fields? E.g.
lastAnnotationsRedefinedCount surely doesn't need the full range right? :)
Sent from my phone
On Jan 25, 2013 11:02 AM, Peter Levart peter.lev...@gmail.com wrote:
On 01/25/2013 06:35 AM, David Holmes wrote:
On 25/01/2013
On 01/25/2013 08:02 PM, Peter Levart wrote:
On 01/25/2013 06:35 AM, David Holmes wrote:
On 25/01/2013 2:36 AM, Peter Levart wrote:
On 01/24/2013 04:45 PM, Peter Levart wrote:
...so it seems that in both cases, adding a boolean to j.l.Class wastes
8 bytes per Class object :-(
Seems to be the
Hi David,
I was surprised to see Usafe report these offsets. See below:
java.lang.Class *instance* field offsets:
Field Type Field Name Offset
-- -- --
Constructor cachedConstructor 12
On 01/25/2013 05:34 PM, Aleksey Shipilev wrote:
On 01/25/2013 08:02 PM, Peter Levart wrote:
On 01/25/2013 06:35 AM, David Holmes wrote:
On 25/01/2013 2:36 AM, Peter Levart wrote:
On 01/24/2013 04:45 PM, Peter Levart wrote:
...so it seems that in both cases, adding a boolean to j.l.Class
On 01/25/2013 05:34 PM, Aleksey Shipilev wrote:
But, otherwise, can't we use java.lang.ClassValue to associate this flag
with each class?
That is my proposed patch. It tries to be space saving and does not
associate the flag with each class, but only with each subclass of
On 01/25/2013 08:37 PM, Peter Levart wrote:
On 01/25/2013 05:34 PM, Aleksey Shipilev wrote:
80 4 ClassValueMap Class.classValueMap
8412 (alignment/padding gap)
What's this? why 12 bytes?
96 4 int Class.classRedefinedCount
Beats me,
On 01/25/2013 08:40 PM, Peter Levart wrote:
On 01/25/2013 05:34 PM, Aleksey Shipilev wrote:
But, otherwise, can't we use java.lang.ClassValue to associate this flag
with each class?
That is my proposed patch. It tries to be space saving and does not
associate the flag with each class, but
On 01/25/2013 05:42 PM, Aleksey Shipilev wrote:
On 01/25/2013 08:37 PM, Peter Levart wrote:
On 01/25/2013 05:34 PM, Aleksey Shipilev wrote:
80 4 ClassValueMap Class.classValueMap
8412 (alignment/padding gap)
What's this? why 12 bytes?
96 4
Hi David,
I think I already have a kind of answer. You wrote it in RFR: 8005232
(JEP-149) Class Instance size reduction:
On 01/06/2013 11:46 PM, David Holmes wrote:
In Java 8, using a 32-bit example, a java.lang.Class instance is 112
bytes consisting of:
- 8 byte object header
- 20
On 01/24/2013 03:34 PM, Peter Levart wrote:
On 01/24/2013 03:10 PM, Alan Bateman wrote:
On 24/01/2013 13:49, Peter Levart wrote:
Should I file a RFE first?
Sorry I don't have time at the moment to study the proposed patch but
just to mention that it has come up a few times, its just that it
Right - I was going to ask if those tools took into account injected fields.
David
On 26/01/2013 3:32 AM, Peter Levart wrote:
Hi David,
I think I already have a kind of answer. You wrote it in RFR: 8005232
(JEP-149) Class Instance size reduction:
On 01/06/2013 11:46 PM, David Holmes wrote:
On 24/01/2013 13:49, Peter Levart wrote:
Should I file a RFE first?
Sorry I don't have time at the moment to study the proposed patch but
just to mention that it has come up a few times, its just that it never
bubbled up to the top of anyone's list. Here's the bug tracking it:
On 01/24/2013 03:10 PM, Alan Bateman wrote:
On 24/01/2013 13:49, Peter Levart wrote:
Should I file a RFE first?
Sorry I don't have time at the moment to study the proposed patch but
just to mention that it has come up a few times, its just that it
never bubbled up to the top of anyone's list.
Peter,
I know this was brought up on your c-i mailing list thread, but it really
feels like a new boolean field in j.l.Class is the cleaner solution (and
infinitely scalable and doesn't require bookkeeping in the Proxy class).
Is there really no existing alignment gap in j.l.Class layout that a
On 01/24/2013 03:40 PM, Vitaly Davidovich wrote:
Peter,
I know this was brought up on your c-i mailing list thread, but it
really feels like a new boolean field in j.l.Class is the cleaner
solution (and infinitely scalable and doesn't require bookkeeping in
the Proxy class). Is there
The boolean seems better from an intent standpoint as well - all this wants
to do is tag a Class as having been internally generated by the proxy.
This information is present at the point of generation, obviously (and the
new. field can be marked final). Doing the tagging via indirection
On 01/24/2013 04:45 PM, Peter Levart wrote:
Is there really no existing alignment gap in j.l.Class layout that a
boolean can slide into?
There might be, I will check.
All instance fields in j.l.Class are either references or ints.
Regards, Peter
On 25/01/2013 2:36 AM, Peter Levart wrote:
On 01/24/2013 04:45 PM, Peter Levart wrote:
Is there really no existing alignment gap in j.l.Class layout that a
boolean can slide into?
There might be, I will check.
All instance fields in j.l.Class are either references or ints.
Instance are
58 matches
Mail list logo
