* 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
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 for the
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
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
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
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 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 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
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,
Hi John,
On Tue, Sep 20, 2011 at 5:58 AM, John Rose john.r.r...@oracle.com 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
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
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 probably a
12 matches
Mail list logo
