ClassValue perf?

[Doug Simon]

We considered using ClassValue in Graal for associating each Node with its NodeClass. Accessing the NodeClass is a very common operation in Graal (e.g., it’s used to iterate over a Node’s inputs). However, brief experimentation showed implementing this with ClassValue performed significantly worse than a direct field access[1]. We currently use ClassValue to link Class values with their Graal mirrors. Accessing this link is infrequent enough that the performance trade off against injecting a field to java.lang.Class[2] is acceptable. The memory footprint improvement suggested in JDK-8031043 would still help.

-Doug

[1] http://hg.openjdk.java.net/graal/graal/file/0b221b4ad707/graal/com.oracle.graal.graph/src/com/oracle/graal/graph/Node.java#l206
[2] http://hg.openjdk.java.net/graal/graal/rev/606959535fd4

> On Apr 27, 2015, at 6:40 PM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
> 
> 
>> On Apr 24, 2015, at 2:17 PM, John Rose <john.r.rose at oracle.com> wrote:
>> 
>> On Apr 24, 2015, at 5:38 AM, Charles Oliver Nutter <headius at headius.com> wrote:
>>> 
>>> Hey folks!
>>> 
>>> I'm wondering how the performance of ClassValue looks on recent
>>> OpenJDK 7 and 8 builds. JRuby 9000 will be Java 7+ only, so this is
>>> one place I'd like to simplify our code a bit.
>>> 
>>> I could measure myself, but I'm guessing some of you have already done
>>> a lot of exploration or have benchmarks handy. So, what say you?
>> 
>> I'm listening too.  We don't have any special optimizations for CVs,
>> and I'm hoping the generic code is a good-enough start.
> 
> A while ago (wow; it’s more than a year already) I was working on:
> 
> [#JDK-8031043] ClassValue's backing map should have a smaller initial size - Java Bug System
> 
> and we had a conversation about it:
> 
> http://mail.openjdk.java.net/pipermail/mlvm-dev/2014-January/005597.html
> 
> It’s not about performance directly but it’s about memory usage and maybe the one-value-per-class optimization John suggests is in fact a performance improvement.  Someone should pick this one up.
> 
>> — John
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev