* 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 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
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
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
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
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 20, 2011, at 1:02 AM, Christian Thalinger wrote:
> 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
>
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
On vacation till October 3. Will be reading email occasionally.
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Hi John,
On Tue, Sep 20, 2011 at 5:58 AM, John Rose wrote:
>
> The tunable parameters CACHE_LOAD_LIMIT and PROBE_LIMIT were chosen by
> looking at the behavior of artificial workloads. Experience with real
> workloads will probably lead to further modifications (under new Change
> Requests). I
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
14 matches
Mail list logo
