Arg ordering on the test path method handle for GwT

[Mark Roos]

> From:
> 
> Rémi Forax <forax at univ-mlv.fr>
> 
> At least it will be easier to debug with a Java Debugger.
If this works I hope to be using the smalltalk debugger (-

> So are convertArgs and invokeGeneric expensive vs nothing and 
invokeExact? 
> 
> I don't follow you here.

My question had to do with run time overhead.  Do you think that 
invokeGeneric
is slower than invokeEaxct at run time? If not then that removes one of 
the
reasons for not using java classes.

> Correct me if i'm wrong but Smalltalk has no overloading for method,
> only for operators. So you need to handle them in a special way
> that may use several gwts.

At least in my experiece smalltalk methods are looked up by receiver class 
and
selector ( the selector does include the arg count  e.g for:to:by  is a 
selector).
The classes of the return and args are not used in the lookup.  So in 
smalltalk
invokeExact and invokeGeneric are equal.  If I were to change to java 
classes
then I would have to use invokeGeneric everywhere.

Methods and operators are the same construct ( e.g. + is a method name) so 
there
is no difference in the lookup.  I beleive that this would mean that there 
is
no overloading in smalltalk based on arg or return types.

Each callsite wlll have a few possible receiver types and so we will have 
a gwt
for each.  If I add support for unboxed types then each site needs to 
check for
these first adding a few more gwts.  In the smalltalk I am referencing a 
gwt
is a x86 compare and jump.  I hope hotspot is as good. (-

regards
mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110114/879b9248/attachment.html