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.thalin...@oracle.com> wrote: > > >> On Apr 24, 2015, at 2:17 PM, John Rose <john.r.r...@oracle.com> wrote: >> >> On Apr 24, 2015, at 5:38 AM, Charles Oliver Nutter <head...@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@openjdk.java.net >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
