Re: Proposal: runtime-modifying Kernel methods should be keywords

On 16/07/07, Charles Oliver Nutter <[e-mail]> wrote:
> John Lam (CLR) wrote:
> >> PS: Incidentally... The comment on the blog entry you gave above
> >> mentions call site caches. I had a student try that for Ruby, and he
> >> found that it couldn't beat Ruby's built-in cache. The reason is
> >> probably the simplicity of Ruby's cache, excellent hardware cache
> >> behavior, and a good cache hit-rate.
> >
> > Not sure what you mean by this - are you saying that the call site method caches did not improve perf at all in a modified version of Ruby?
>
> I imagine he means that since Ruby already has method caches in other
> forms, adding call-site caches did not help in the existing
> implementation. But that's a one-sided view point; call site caches in
> JRuby, for example, would help immensely, because it would eliminate (in
> most cases) all method lookup *and* invocation indirection. This in turn
> would enable HotSpot to much more easily inline the actual code being
> called, where having many levels of indirection between the call site
> and the target method makes it much harder. Call site caches are not
> only about avoiding method lookup in our case...they're about making
> execution as straight a line as possible.

I was commenting on the comment. What you are doing is still a bit
different, and quite interesting. I'm curious to learn how well this
actually works because there are some arguments against it too. You
still want the code to be generic, so I assume that you select between
the common case and the not so common case with if statements. The
common case can then be inlined. Do I understand that correctly? If
so, then you avoid the method call overhead, but the if-statement will
still function as a boundary for optimizations. Really good compilers
might be able to do something with it, and I don't know if HotSpot
does. HotSpot sticks to the faster analyses+optimizations because
everything it does adds to the run time of the Java program, so I
would expect most of its optimizations to be within single basic
blocks. The inlining you mention does not increase basic block size.
The numbers you gave on your blog entry were for an unsafe version,
for a safe version I would expect them to be worse.

Peter