On Dec 8, 2011, at 1:55 AM, Florian Weimer wrote:
> * John Rose:
>
>> But, in order to respect the "general aim" you are mentioning, I have
>> unhoisted one of the two words from the Class instance itself. This
>> will cause a minor slowdown in JSR 292 use cases.
>
> What about using ClassValue
* John Rose:
> But, in order to respect the "general aim" you are mentioning, I have
> unhoisted one of the two words from the Class instance itself. This
> will cause a minor slowdown in JSR 292 use cases.
What about using ClassValue for the various caches instead?
enumConstants and enumConstan
On Dec 4, 2011, at 6:25 PM, David Holmes wrote:
>>> In the mean time, all the non-Groovy, non-JRuby, non-Nashorn, etc.
>>> uses of class Class and all the classes not visible in those
>>> environments when they are being used will be larger.
>>>
>>> Adding the fields may be the right time/space
On 5/12/2011 11:03 AM, Rémi Forax wrote:
On 12/05/2011 01:27 AM, Joe Darcy wrote:
On 12/4/2011 2:13 PM, Rémi Forax wrote:
On 12/04/2011 08:38 PM, Joe Darcy wrote:
Are there alternatives to adding two new fields to java.lang.Class?
I assume most Class'es won't have ClassValue information assoc
On 12/05/2011 01:27 AM, Joe Darcy wrote:
On 12/4/2011 2:13 PM, Rémi Forax wrote:
On 12/04/2011 08:38 PM, Joe Darcy wrote:
Hi John,
Are there alternatives to adding two new fields to java.lang.Class?
I assume most Class'es won't have ClassValue information associated
with them.
-Joe
If y
On 12/4/2011 2:13 PM, Rémi Forax wrote:
On 12/04/2011 08:38 PM, Joe Darcy wrote:
Hi John,
Are there alternatives to adding two new fields to java.lang.Class?
I assume most Class'es won't have ClassValue information associated
with them.
-Joe
If you use Groovy, JRuby or Nashorn in your co
On 12/04/2011 08:38 PM, Joe Darcy wrote:
Hi John,
Are there alternatives to adding two new fields to java.lang.Class? I
assume most Class'es won't have ClassValue information associated with
them.
-Joe
If you use Groovy, JRuby or Nashorn in your code, all visible classes
will use this tw
Hi John,
Are there alternatives to adding two new fields to java.lang.Class? I
assume most Class'es won't have ClassValue information associated with them.
-Joe
On 12/3/2011 7:59 PM, John Rose wrote:
The caching ClassValue is still under review. I took the opportunity to remove
-Xlint war
The caching ClassValue is still under review. I took the opportunity to remove
-Xlint warnings (adding type parameters) and refactor for better readability.
Also, Mike Duigou pointed out that there was still a dependency on
ClassValue.equals == Object.equals, which could create a side-channel b
On Sep 19, 2011, at 2:58 PM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/7030453/webrev.00
After some comments from David Holmes (thanks David!) I added internal comments
about race conditions.
I refreshed the webrev with the additional comments. I also changed one
variable to be vol
On Sep 19, 2011, at 11:58 PM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/7030453/webrev.00
src/share/classes/java/lang/ClassValue.java:
233 /** Value stream for for hashCodeForCache. See similar structure in
ThreadLocal. */
Two for's.
578 * from the ehad of a non-null
On Sep 19, 2011, at 7:00 PM, Krystal Mok wrote:
> FYI, There's one, java.lang.Integer's cache size is tunable via JVM command
> line flag -XX:AutoBoxCacheMax, which in turn sets Java system property
> "java.lang.Integer.IntegerCache.high", and affects the Integer cache size.
> But that's probab
http://cr.openjdk.java.net/~jrose/7030453/webrev.00
The existing JDK 7 implementation of ClassValue is a place-holder which is
defective in several ways:
- It uses cascaded WeakHashMaps to map from (Class, ClassValue) pairs to
values, which is slow.
- It does not lock the root WeakHashMap, whi
13 matches
Mail list logo
