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