On Sep 11, 2008, at 3:36 AM, Charles Oliver Nutter wrote:
> the return values from the
> actual call is no longer the last operation in the method. I don't
> doubt
> the JVM can reduce that cost, but it could never be a tail call
> because
> it's not a tail call. How common is this?
It will be common at the boundary between Java and dynlangs, where
the dynlang is returning Object to a more specific type expected by
the java caller. I already special-case this a little in the
interpreter to support the bootstrap method call, which (as you know)
returns Object to an arbitrary invokedynamic instruction. Jochen
already noted the other case, where Java returns a primitive back to
a dynlang. There might be a way to special-case that; not sure.
On Sep 11, 2008, at 4:42 AM, Jochen Theodorou wrote:
> John Rose schrieb:
>> It will dispatch exactly the way the reflective method does:
>> - no dispatch for static methods
>> - virtual dispatch for class methods
>> - interface dispatch for interface methods
>
> sure, yes... I would prefer a non virtual dispatch for class methods,
> but I am used to it. What I did target was overloading.
No, the java.dyn APIs do not help with overload resolution. They
give you power to emulate all the invoke* bytecode instructions, but
not (directly) higher level concepts from Java.
>> The unreflectSpecial method call creates a non-dispatching method
>> handle
>> (if the caller has the rights to do so, which are limited).
>
> this can be used to generate calls to super methods? It is probably
> thought for private only...
Pretty much; it gives you the ability to emulate "super.foo(x)" in an
arbitrary interpreter or threaded-code system. (Remember the
discussion a while ago with John Wilson about Ng and that missing
functionality in reflection...)
You could also use invokespecial method handles (with care) to
perform exactly-typed calls. E.g.:
if (recv.getClass() == MY_EXPECTED_CLASS_EXACTLY)
return expectedClassSpecialMH.invoke(recv);
else ... perform virtual stuff
Since this could break the verifier if misused, it would have to be
privileged code that does this. It's not implemented yet, mainly
because I haven't thought through the security checks.
> what for example if I have one mehod
> that takes 10 arguments? That may be a rare case, but it is a possible
> case. So either I do some Object[] based magic here (which I currently
> don't know how it could look like) or I have a problem.
Plan of "record" (in my head) is to supply arglist reification as a
fallback for hairy signatures. Reification as ArgumentList or Object
[] in the worst case. Once everything boils down to the reflective
style Object[] it will be slow, but you can then compose everything
in terms of the signature Object(Object[]) or just Object(Object).
There is varargs support in MethodType to help with this (and with
reflective style invokes, in general).
On Sep 11, 2008, at 5:09 AM, Jochen Theodorou wrote:
>>
>> I don't think there's a reason that a Java stack frame ever *has
>> to* be
>> created unless the JVM actually needs it; and in this case it does
>> not.
>
> I see thatthe same way, but maybe John does see it in a different way,
> since he is the VM guy here.
I see a stack frame, but there are ways to hide such frames;
reflection does. Reflection, remember, often must return a primitive
value to a caller expecting Object (from reflect.Method.invoke).
Nobody sees the hidden frames except the JVM. I'll count this
discussion as a vote for spackling over those frames.
> yes, but the point is, that I still need code generation at
> runtime. If
> it where only a fixed set of maybe 256 classes, then I could generate
> them beforehand
While I would like to promise the complete abolition of code
generation from the start, all we can deliver at present is a
significant reduction; complete abolition is a goal to be reached
iteratively. It's a worthy goal, especially for small devices like
the gphone (or iphone if Apple ever lets Java in).
> I don't have problems with the cost of the MethodHandle, only with
> runtime code generation... but maybe that fear is without reason,
> because you work without any specific types in such an adapter. If
> there
> is no specific type (besides some primitives maybe), then there is no
> class loading problem with the class loader that I have to use to
> "store" my class.
That's an important point. The 5**3 == 125 is the real number to
worry about, not the number of different classes in the world.
It will be routine to work with adapters parameterized by Class
objects. At least, that's how I'm structuring the lower levels of
the prototype. It feels just like working with generic types: The
signatures are all erased to Object, and you pass explicit Class
object wherever the runtime needs to know the type.
-- John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
