John Rose schrieb:
> On Sep 9, 2008, at 12:32 PM, Jochen Theodorou wrote:
>
>> I wonder how invokedynamic would behave here... does invokedynamic add
>> stack frames? if not, then there is a chance that Class.forName would
>> work again. If its adding stack frames, then I see no chance.
>
> Invokedynamic does not visibly add stack frames for linked calls, but
> when a call is not linked it redirects to the bootstrap method, which
> therefore appears on the stack.
On further thought I have some questions here... is it possible to have
custom MethodHandles? Custom in the sense of extending MethodHandle...
if not, then I am not sure how types are converted. For example I do
foo.bar(x)
where bar on foo takes a String and x is a GString. Normally I need to
coerce the argument into a String using toString. But I never understood
how I do apply this kind of transformation.
In fact I do not really find ways for my basic problems with the current
version of jsr292 I have. This is efficient single argument
transformation (GString to String for example), group argument
transformation 1->n (spreading an data structure of unknown length),
group argument transformation n->1 (collecting the arguments into a data
structure; used for vargs calls).
I also never understood why the bootstrap method must make the call...
why not letting it produce the handle?
anyway, I always thought the type transformations must be done by a
custom a MethodHandle. Probably like this:
GString2StringSingleArgument extends MethodHandle {
MethodHandle stringTakingMethod;
MethodType type;
SingleGStringConverter(MethodHandle stringTakingMethod) {
this.stringTakingMethod=stringTakingMethod;
this.type = MethodType.make(void.class,new Class[]{Object.class});
}
public void invoke(Object gs) {
// invalidate cache if gs is not a GString (missing!)
// invoke target method
stringTakingMethod.invoke(gs.toString());
}
public MethodType getType(){ return type;}
}
Now the problems I have with this are simple... I need loads of custom
method handles for many types I have to transform. I understand that the
annonymous class loader is probably the idea to handle this. Also I
think this here will add a stack frame, or not? that's something I don't
want to have, because of first because of Hotspot and second because of
method like Class.forName(String).
What I wished for is a way to directly manipulate the arguments... for
example something that allows me to to take argument xy from the
argument stack and replace it with a new
Object.MethodHandles#dropArgument and #appendArgument can not handle
this.... I would have wished for MethodHandles#coerceArguments(int pos,
MethodHandle converter, Class[] types):MethodHandle which takes a number
of arguments defined by converter from the argument stack and replaces
them with a number of arguments specified in type and amount by types.
As long as we don't have tuples and a way to expand them in the VM we
can not do this like here, but we can do this for a single argument.
MethodHandles#coerceArgument(int pos, MethodHandle
converter):MethodHandle. Converter would then describe a single argument
taking method which replaces the argument on the argument stack with its
return value. But that's not all.. this needs to be combined with the
MethodHandle we want to call... MethodHandles#useConverter(MethodHandle
converter, MethodHandle method):MethodHandle, where converter is simply
executed first to replace an argument and then method is called with the
new set of arguments. With this I can also handle varags calls by
combining it with dropping and converting the argument I need to an
array of my need.. or other types of calls where I have to reduce the
number of arguments. For adding additional arguments I usually have one
argument that needs to be expanded by adding arguments at certain
positions and then the original argument is dropped. That's a bit more
complicated, but could be done in the same style.
The goal would be to not to have countless small classes and to not to
have additional stack frames. I thought I saw things like these on the
invokedynamic early draft, but maybe I am wrong... I am not sure now,
because there is nothing to be seen in John's javadocs... or do I have
an old version?
bye Jochen
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
