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

Reply via email to