On Wed, Apr 29, 2015 at 4:02 AM, Doug Simon <doug.si...@oracle.com> wrote: > 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.
That's what I'm banking on too. My case is similar to Groovy's: I need a way to *initially* get the metaclass for a given JVM class. Unlike Groovy, however, we still have to wrap Java objects in a JRuby-aware wrapper, so subsequent accesses of the class via that object are via a plain field. So the impact of ClassValue will mostly be at the border between Ruby and Java, when we need to initially build that wrapper and put some metaclass in it. Of course the disadvantage of the wrapper is the wrapper itself. If we could inject our IRubyObject interface into java.lang.Object my life would be much better. But I digress. > The memory footprint improvement suggested in JDK-8031043 would still help. I'll have to take a look at that. We're pretty memory-sensitive since Ruby's already fairly heap-intensive. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
