On Sep 3, 2008, at 11:56 PM, John Rose wrote:
>
> On Sep 3, 2008, at 2:23 PM, Attila Szegedi wrote:
>
>> Well, we certainly live in interesting times, at least as far as
>> JavaScript runtimes go...
>
> To paraphrase a loan commercial: "When VMs compete, language
> implementors win."
>
>> TraceMonkey's type specialization seems like something that'd make
>> quite a lot of sense. Well, it's trading off memory (multiple
>> versions
>> of code), for speed. Basically, if you'd have a simplistic
>>
>> function add(x,y) { return x + y; }
>>
>> that's invoked as add(1, 2) then as add(1.1, 3.14), then as
>> add("foo",
>> "bar"), you'd end up with three methods on the Java level:
>>
>> add(int,int)
>> add(double,double)
>> add(String, String)
>
> That's something you can build in JVM bytecodes using invokedynamic.
> The call site should use not a generic signature but a signature
> which reflects exactly the types known statically to the caller, at
> the time it was byte-compiled.
>
> So "x+1" would issue a call to add(Object,int), but "x+y" might be
> the generic add(Object,Object).
>
> When the call site is linked (in the invokedynamic "bootstrap
> method"), a customized method can be found or created, perhaps by
> adapting a more general method.
>
> The language runtime can also delay customization, choosing to
> collect a runtime type profile, and then later relink the call site
> after a warmup period, to a method (or decision tree of methods)
> which reflects the actual profile.
Indeed, that's exactly what I had in mind.
>> Combined with HotSpot's ability to inline through
>> invokedynamic, we could probably get the same optimal type narrowed,
>> inlined code that TraceMonkey can.
>
> Yes, that's the easier way to get customization, via inlining. We
> probably need an @Inline annotation (use this Power only for Good).
Why would we need an explicit inline annotation? I was under
impression that use of invokedynamic would open the opportunity for
HotSpot to inline the code with certain types of MethodHandles.
>> It seems to me that type specialization is a more broadly
>> applicable, more generic, and thus more powerful concept that allows
>> for finer-grained (method level) specializations/optimizations than
>> doing it on a level of whole classes.
>
> The V8 technique sounds like a successor to Self's internal classing
> mechanism; it sounds more retroactive. A key advantage of such
> things is removal of indirections and search. If you want the "foo"
> slot of an object in a prototype based language, it's better if the
> actual data structures have fewer degrees of freedom and less
> indirections; ideally you use some sort of method caching to link
> quickly to a "foo" method which performs a single indirection to a
> fixed offset. If the data structure has many degrees of freedom
> (because there is no normalization of reps.) then you have to treat
> the object as a dictionary and search for the foo more often. You
> might be able to lookup and cache a getter method for obj.foo, but it
> would be even better to have a fixed class for obj, which you test
> once, and use optimized getters and setters (of one or two
> instructions) for all known slots in the fixed class.
Yeah, my wet dream of combining this with the type specialization of
methods above, is that you could have this JS code:
function abs(c)
{
return Math.sqrt(Math.sqr(c.re*c.re)+Math.sqr(c.im*c.im));
}
print(abs({re:5, im:6}));
print(abs({re:7, im:9});
And it would end up being specialized as this (in Java):
class retrofitting:
public class Complex { int re, im; } // int, cause all observed
arguments so far were ints
then type specialization:
public double abs(Complex c) // returns double b/c of Math.sqrt
{
... uses GETFIELD on c for re and im...
}
and then HotSpot further JITs it to efficient native code.
The only difference is that the class name as generated would probably
be $$autogenerated$$0fc45e9a or something of similar beauty, and not
"Complex" :-)
Attila.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
