Le 06/08/2009 02:40, Charles Oliver Nutter a écrit :
On Wed, Aug 5, 2009 at 7:30 PM, Rémi Forax<fo...@univ-mlv.fr> wrote:
I have seen some small rooms of improvement in the JRuby code
(apart from replacing DynamicMethod by MethodHandle which is
what must be done but which is also in my opinion a more than one week job
:)
Nah, it's a day at most.
=> Cool :)
Here's the process:
1. When generating DynamicMethods that point at real Java code, also
attach target class, method name, and signature info.
2. Use this info at runtime when preparing the call sites.
You should try to cache the method handle in the DynamicMethod
to reuse the same MH for several call sites.
And even if we went with a stupid-simple solution, I could switch on
JRuby's reflection-based mode and simply unreflect the Method object
each ReflectedMethod (extends DynamicMethod) would contain. The fact
that we can juggle handle information immediately before installing it
in the call site makes everything pretty easy.
And here's a couple questions for you and John:
1. If we desired to expand JRuby's monomorphic inline caching in indy
mode, could we simply chain together a series of GWTs that perform
type comparisons? So we'd have something like
at call site:GWT1
test: is receiver a String
target: call cached String method
fallback: GWT2
test: is receiver an Array
target: call cached Array method
fallback: GWT3
...
fallback: slow lookup and perhaps add to or edit the GWT
chain based on some heuristic
Since the entire sequence would still inline (ideally) it would be
similar to the regenerated call site logic that the DLR does...except
way better, because it wouldn't interfere with the eventual targets
inlining into the caller.
Speaking for what I am knowing, i.e
without a special wildcard rule for inlining,
It's working for bi-morphic call but after that
local vtable (or selector table) implemented using table or
lookup switch are more efficient.
Something like:
let receiverClass = receiver.getClass();
switch(receiverClass.hashCode()) {
case 0x1345678:
return ...
case 0x678456:
// here there is a collision, very rare in practice, fallback to
if..else
if (receiverClass == String.class) {
} else {
}
...
}
2. Have you (or anyone else) thought much about how indy might
eventually play with the tiered compiler? I could see the two working
extremely well together. In my head, the first tier compilation would
happen quickly and know about method handle chains, but also install
appropriate profiling hooks that can gather information about those
chains. For example, in the GWT case above, it would include branch
profiling to see which of the types in the PIC were getting hit most
often. Then the second tier compiler could do a better job of
optimizing those paths.
I know the tiered compiler work has slowed over the past few months,
but I've also heard plans are still to make it a reality. Tiered
compilation combined with indy would certainly be worth more than the
sum of its parts, since dynamic, multi-stage optimization is the name
of the game for fast dynamic languages.
I wonder if tiered compilation is still an active project
since Steve Goldman passed away.
I know that someone new (I don't remember who)
was in charge to this project but I haven't seen
any news since.
- Charlie
Rémi
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
