Arg ordering on the test path method handle for GwT

Mark Roos mroos at roos.com
Thu Jan 13 10:02:58 PST 2011


> From:
> Rémi Forax <forax at univ-mlv.fr>

> Also it's better to use directly Java object instead of your own object,
> e.g. use Object instead of RtObject. If RtObject has methods, you can
> refactor them has static method and use invokedynamic to call them on
> a plain old Object.
> Of course, this doesn't work if you have states in your object.

I have wondered (worried) about that and its impact on performance.  I do
need to have state but the state is the pointer to the array of method 
tables
for that Smalltalk class.  I have about 2500 classes and one thought would 
be
to just create 2500 java mirro classes with no methods just the method 
table instance var.

But it seems to me that then my methods will have type conversions 
everywhere
effectively making everything invokeGeneric.  So its not clear what I gain 
by
having the Java versions of each class.
 
My test method then would be:
        convertArgs dropArgs testMH  vs just dropArgs testMH
And may fast path
        invokeGeneric doitMH  vs invokeExact doitMH
So are convertArgs and invokeGeneric expensive vs nothing and invokeExact? 
 

The cost of my current approach may be with integers and floats.  I 
suspect that
hot spot knows how to deal with these objects but in my case they are 
boxed again.
But I can't extend them to add the ST method array pointer.  It would be 
the
same if java was to support ints as a variant of a object pointer.  This 
would 
require that I test at each callsite for the shape of the object and 
branch
to the integer/float handler before testing for the class.In this case 
each
callsite would have a required gwt for each special type before it went to 
the
normal types.

I think all this can be done I just don't know enough about hot spot to 
make
the trade-offs yet.

thanks for listening
mark


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110113/22a707cc/attachment.html 


More information about the mlvm-dev mailing list